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ABSTRACT 


There  is  a  growing  movement  throughout  the  Department 
of  Defense  (DoD)  towards  the  implementation  of  Network 
Centric  Warfare  (NCW)  .  In  an  effort  to  transition  to  NCW, 
the  Navy  has  fielded  many  different  technologies.  One 
system  exploiting  new  technologies  in  the  Intelligence, 
Surveillance,  and  Reconnaissance  (ISR)  domain  is  the  Joint 
Fires  Network/Tactical  Exploitation  System-Navy  (JFN/TES- 
N)  ,  which  was  developed  from  the  Army  Tactical  Exploitation 
System,  (TES-A) . 

This  system  was  developed  rapidly  and  uniquely  for 
fleet  deployment  in  accordance  with  the  interim  acquisition 
guidance  signed  by  the  Honorable  Paul  Wolfowitz .  This 
guidance  authorized  Evolutionary  Acquisition  following  a 
Spiral  Development  process  in  lieu  of  the  "traditional" 
cold  war  process  described  in  the  DoD  5000  series 
publications.  Assuming  that  JFN/TES-N  will  be  viewed  as  a 
successful  acquisition,  several  Navy  personnel  have  stated 
that  it  may  become  the  model  for  future  C4I  (and  other) 
system  acquisitions.  This  thesis  seeks  to  help  develop  that 
model.  The  objectives  of  this  thesis  are: 

•  To  examine  whether  the  TES-N  acquisition  process 

is  an  appropriate  model  of  Evolutionary 

Acquisition  following  a  Spiral  Development. 

•  To  identify  and  make  recommendations  for  changes 
or  improvements  to  the  TES-N  acquisition  program, 
so  it  can  be  used  as  a  more  appropriate  model  for 
Evolutionary  Acquisition  following  a  Spiral 
Development . 
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This  thesis  concludes  that  Evolutionary  Acquisition 
following  a  Spiral  Development  shown  with  the  JFN/TES-N 
system  is  an  acquisition  policy  that  is  appropriate  for 
programs  of  the  same  size  and  scope,  but  larger  more 
complex  programs  will  not  have  as  much  success.  Yet,  in 
order  for  the  JFN/TES-N  program  and  future  programs  using 
Evolutionary  Acquisition  following  a  Spiral  Development  to 
succeed,  changes  have  to  be  made  in  policies  such  as 
budgetary  submissions,  test  and  evaluation,  policy, 
process,  and  training. 
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EXECUTIVE  SUMMARY 


There  is  a  growing  movement  throughout  the  Department 
of  Defense  (DoD)  towards  the  implementation  of  Network 
Centric  Warfare  (NCW)  .  In  an  effort  to  transition  to  NCW, 
the  Navy  has  fielded  many  different  technologies.  One 
system  exploiting  new  technologies  in  the  Intelligence, 
Surveillance,  and  Reconnaissance  (ISR)  domain  is  the  Joint 
Fires  Network/Tactical  Exploitation  System-Navy  (JFN/TES- 
N)  ,  which  was  developed  from  the  Army  Tactical  Exploitation 
System,  (TES-A) . 

This  thesis  explains  that  JFN/TES-N  was  developed 
rapidly  and  uniquely  for  fleet  deployment  in  accordance 
with  the  interim  acquisition  guidance  signed  by  the 
Honorable  Paul  Wolfowitz.  This  guidance  authorized 
Evolutionary  Acquisition  following  a  Spiral  Development 
process  in  lieu  of  the  "traditional"  cold  war  process 
described  in  the  DoD  5000  series  publications  .  Assuming 
that  JFN/TES-N  will  be  viewed  as  a  successful  acquisition, 
several  Navy  personnel  have  stated  that  it  may  become  the 
model  for  future  C4I  (and  other)  system  acquisitions.  This 
thesis  seeks  to  help  develop  that  model.  The  objectives  of 
this  thesis  are: 

•  To  examine  whether  the  TES-N  acquisition  process 
is  an  appropriate  model  of  Evolutionary 
Acquisition  following  a  Spiral  Development. 

•  To  identify  and  make  recommendations  for  changes 
or  improvements  to  the  TES-N  acquisition  program, 
so  it  can  be  use  as  a  more  appropriate  model  for 
Evolutionary  Acquisition  following  a  Spiral 
Development . 
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In  order  to  examine  the  TES-N  acquisition  process  as  a 
model  for  future  system  acquisitions ,  and  make 
recommendations  for  changes  to  it  if  appropriate,  this 
thesis  reports  the  results  of  a  literature  search  to 
explicitly  determine  the  characteristics  of  each  of  these 
documented  processes.  Next,  this  thesis  extracts  the 
salient  characteristics  of  the  TES-N  acquisition  process 
through  interviews  with  key  personnel  at  the  TES-N  program 
office.  Next,  this  thesis  use  the  breakdown  of  Evolutionary 
Acquisition  following  a  Spiral  Development  in  the  article, 
The  Promise  and  Perils  of  Spiral  Acquisition:  A  Practical 
Approach  to  Evolutionary  Acquisition  by  COL  Wayne  M. 
Johnson,  USAF  (Ret)  and  Carl  0.  Johnson  as  a  model  for 
Evolutionary  Acquisition  following  a  Spiral  Development  and 
the  DoD  5000  series  documents  as  a  model  for  the 
"traditional"  acquisition  policy,  to  reveal  key  points  that 
highlight  relative  differences  between  the  two  as  a  basis 
for  characterizing  the  JFN/TES-N  acquisition  process.  Next, 
the  results  of  surveying  fleet  personnel  show  the  user' s 
opinion  on  the  new  system's  performance.  Finally,  this 
thesis  reports  the  results  of  interviews  of  operators  and 
decision  makers  aboard  the  USS  CORONADO,  flagship  of 
Commander  Third  Fleet  (C3F)  and  makes  recommendations  based 
upon  my  findings  for  future  programs  with  an  acquisition 
process  similar  to  Evolutionary  Acquisition  following  a 
Spiral  Development . 

This  thesis  concludes  that  Evolutionary  Acquisition 
following  a  Spiral  Development  shown  with  the  JFN/TES-N 
system  is  an  acquisition  policy  that  is  appropriate  for 
programs  of  the  same  size  and  scope,  but  larger  more 
complex  programs  will  not  have  as  much  success.  Yet,  in 


order  for  the  JFN/TES-N  program  and  future  programs  using 
Evolutionary  Acquisition  following  a  Spiral  Development  to 


succeed,  changes  have  to  be  made  in  policies 
budgetary  submissions,  test  and  evaluation, 
process,  and  training. 


such  as 
policy  f 
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I. 


INTRODUCTION 


A .  BACKGROUND 

There  is  a  growing  movement  throughout  the  Department 
of  Defense  (DoD)  towards  the  implementation  of  Network 
Centric  Warfare  (NCW) .  In  efforts  to  transition  to  NCW,  the 
Navy  has  fielded  many  different  systems  and  technologies. 
One  such  system  exploiting  new  technologies  in  the 
Intelligence,  Surveillance,  and  Reconnaissance  (ISR)  domain 
is  the  Joint  Fires  Network/Tactical  Exploitation  System- 
Navy  (JFN/TES-N) ,  which  was  developed  from  the  Army's 
Tactical  Exploitation  System,  (TES-A) . 

This  system  was  developed  rapidly  and  uniquely  for 
fleet  deployment  in  accordance  with  the  interim  acquisition 
guidance  signed  by  the  Honorable  Paul  Wolfowitz .  This 
guidance  authorized  Evolutionary  Acquisition  following  a 
Spiral  Development  process  in  lieu  of  the  "traditional" 
cold  war  process  described  in  the  DoD  5000  series 
publications.  Assuming  that  JFN/TES-N  will  be  viewed  as  a 
successful  acquisition,  several  Navy  personnel  have  stated 
that  it  may  become  the  model  for  future  C4I  (and  other) 
system  acquisitions.  This  thesis  seeks  to  help  develop  that 
model . 

B .  OBJECTIVE 

The  objectives  of  this  thesis  are  two-fold: 

•  To  examine  whether  the  TES-N  acquisition  process 
is  an  appropriate  model  of  Evolutionary 
Acquisition  following  a  Spiral  Development. 
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•  To  identify  and  make  recommendations  for  changes 
or  improvements  to  the  TES-N  acquisition  program, 
so  it  can  be  use  as  a  more  appropriate  model  for 
Evolutionary  Acquisition  following  a  Spiral 
Development . 

C.  SCOPE  AND  METHODOLOGY 

1 .  Scope 

This  thesis  examined  the  JFN/TES-N  acquisition  process 
to  determine  whether  this  process  should  be  followed  as  is, 
modified,  or  abandoned  in  future  acquisitions .  Based  on 
this  analysis,  I  made  recommendations  on  what  should  be 
retained  as  future  doctrine  and  what  needed  to  be  fixed.  I 
also  examined  any  problems  and  recommended  solutions. 

2 .  Methodology 

Within  DoD  today,  there  are  two  different  documented 
development  and  acquisition  processes:  the  traditional 
process  documented  in  the  DoD  5000  series  and  the  newer 
Evolutionary  Acquisition  following  a  Spiral  Development 
process  described  in  the  October  30,  2002  memorandum  signed 

by  the  Deputy  Secretary  of  Defense,  the  Honorable  Paul 
Wolf owit z . 

In  order  to  assess  the  suitability  of  the  TES-N 
acquisition  process  as  a  model  for  future  system 
acquisitions,  and  make  recommendations  for  changes  to  it  if 
appropriate,  I  conducted  a  literature  search  to  explicitly 
determine  the  characteristics  of  each  of  these  documented 
processes .  Next,  I  determined  the  salient  characteristics 
of  the  TES-N  acquisition  process  through  interviews  with 
key  personnel  at  the  TES-N  program  office.  Next,  I  used  the 
breakdown  of  Evolutionary  Acquisition  following  a  Spiral 
Development  in  the  article,  The  Promise  and  Perils  of 
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Spiral  Acquisition :  A  Practical  Approach  to  Evolutionary 
Acquisition  by  COL  Wayne  M.  Johnson,  USAF  (Ret)  and  Carl  0. 
Johnson  as  a  model  for  Evolutionary  Acquisition  following  a 
Spiral  Development  and  the  DoD  5000  series  documents, 
specifically  DODI  5000.2  Operation  of  the  Defense 
Acquisition  System  (Including  Change  1  4JAN2001),  as  a 

model  for  the  "traditional"  acquisition  policy,  to  reveal 
key  points  that  highlight  relative  differences  between  the 
two  as  a  basis  for  characterizing  the  JFN/TES-N  acquisition 
process.  I  then  surveyed  fleet  personnel  to  determine  their 
opinion  on  the  new  system's  performance.  Finally,  I 
interviewed  operators  and  decision  makers  aboard  the  USS 
CORONADO,  the  flagship  of  Commander  Third  Fleet  (C3F)  and 
make  recommendations  based  upon  my  findings  for  future 
programs  with  an  acquisition  process  similar  to 
Evolutionary  Acquisition  following  a  Spiral  Development. 

D .  RESEARCH  QUESTIONS 

•  What  acquisition  process  is  being  used  for  the 

JFN/TES-N? 

•  What  is  the  "traditional"  acquisition  process 

described  by  the  5000  series  publications? 

•  What  is  Evolutionary  Acquisition  following  a 
Spiral  Development ? 

•  How  does  the  JFN/TES-N  acquisition  process 

compare  to  the  "traditional"  cold  war  philosophy 
described  in  the  5000  series  publications  and  the 
new  process  of  Evolutionary  Acquisition  following 
a  Spiral  Development? 

•  What  recommendations  can  be  made  to  improve  the 

Evolutionary  Acquisition  following  a  Spiral 
Development  process  based  on  the  TES-N  model? 
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E.  ORGANIZATION  OF  THE  THESIS 

Chapter  II  provides  the  role,  history,  and  background 
of  TES-N,  starting  with  how  it  first  was  developed  by  the 
Army,  and  then  was  adopted  by  the  Navy. 

Chapter  III  provides  a  definition  and  description  of 
the  "traditional"  acquisition  process  as  described  in  the 
DoD  5000  series  publications. 

Chapter  IV  defines  Evolutionary  Acquisition  following 
a  Spiral  Development .  A  breakdown  of  Evolutionary 
Acquisition  following  a  Spiral  Development  is  described  by 
COL  Wayne  M.  Johnson,  USAF  (Ret)  and  Carl  0.  Johnson, 
article.  The  Promise  and  Perils  of  Spiral  Acquisition:  A 
Practical  Approach  to  Evolutionary  Acquisition . 

Chapter  V  begins  by  further  explaining  why  the  United 
States  needs  to  change  their  acquisition  process  in  order 
to  provide  timely  technology  and  intelligence  to  the  war 
fighter.  Next,  it  explains  the  JFN/TES-N  Evolutionary 
Acquisition  following  a  Spiral  Development .  This  chapter 
then  uses  the  breakdown  of  spiral  development  in  the 
Johnson  and  Johnson  article,  as  a  model  for  Evolutionary 
Acquisition  following  a  Spiral  Development  and  the  DoD  5000 
series  documents  as  a  model  for  the  "traditional" 
acquisition  policy,  to  reveal  key  points  that  highlight 
relative  differences  between  the  two  as  a  basis  for 
characterizing  the  JFN/TES-N  acquisition  process. 

Chapter  VI  provides  conclusions  and  recommendations  on 
what  can  be  improved  and  what  should  be  used  in  future 
acquisition  programs  such  as  the  TES-N. 
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II.  HISTORY  OF  THE  TACTICAL  EXPLOITATION  SYSTEM 


The  goal  of  this  chapter  is  to  provide  the  reader 
background  on  the  role  of  the  TES  in  its  military 
environment.  It  also  provides  a  history  of  the  TES-N, 
starting  with  how  TES  first  was  developed  by  the  Army  and 
then  adopted  by  the  Navy.  It  will  further  present  a 
background  of  the  TES-N  architecture  and  a  description  of 
how  TES-N  operates  in  its  environment. 

A .  BACKGROUND 

In  1973,  the  Army  created  the  Army  Space  Program 
Office  (ASPO)  ,  whose  role  was  "developing  systems  to 
integrate  current  and  emerging  national  capabilities  into 
the  decision-making  process,  a  kind  of  networked 
information  system."  (Littman,  2002,  p.  6)  Since  that  time, 
other  programs  have  developed  similar  offices  known  as 
Tactical  Exploitation  of  National  Capabilities  (TENCAP) .  In 
1995,  the  ASPO  decided  to  build  a  system  called  the 
Tactical  Exploitation  System  (TES) (for  simplicity  in  the 
thesis,  the  Army  program  will  be  called  TES-A)  that  would 
consolidate  intelligence  such  as  national  and  theater 
imagery  systems  into  one  Multi-Intelligence  system.  It 
would  be  a  scaled  down  version  of  a  few  existing  TENCAP 
systems .  These  TENCAP  systems  to  be  replaced  by  TES-A  were 
the  Modernized  Imagery  Exploitation  system  (MIES)  ,  Advanced 
Electronic  Processing  and  Dissemination  System  (EPDS) ,  and 
the  Enhanced  Tactical  Radar  Correlator  (ETRAC) .  The  TES-A 
alone  would  provide  the  functional  capability  of  all  three 
systems.  (Littman,  2002,  p.  38) 
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The  eventual  commercial  developer  of  the  TES-A, 
Northrop  Grumman  (NG) ,  stated  that  they  were  to  deliver  a 
system,  which  was : 

Assured  receipt  of  all-weather,  day/night 
intelligence,  surveillance,  reconnaissance  (ISR) 
information  from  national,  theater  and  tactical 
plat  forms. ..through  all  phases  of  military 
operations,  providing  a  real-time,  correlated 
imagery  and  SIGINT  picture  directly  to  the 
tactical  warfighter.  (Littman,  2002,  p.  38) 

The  Army  developed  the  TES-A  as  a  dual-base  system 
consisting  of  a  TES  Main  (TES-M)  and  a  TES  Forward  (TES-F)  . 
"The  main  element  (TES-M)  remains  in  relatively  secure 
locations  and  provides  detailed  intelligence  analysis  and 
support  to  the  forward  element  (TES-F)."  (Littman,  2002,  p. 
7)  TES-F,  unlike  TES-M,  is  brought  into  forward  areas  and 
operated  on  the  battlefield.  The  maneuverability  of  TES-F 
can  be  seen  in  Figure  1  below. 


Figure  1  .  TES-Forward,  Notice  How  the  System  Can  Be 

Mounted  and  Easily  Transported  on  Light  Trucks  and 
HMMWV' s  (From:  Littman,  2002,  p.  39). 
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In  1997,  the  Navy  began  to  see  the  potential  benefits 
of  adopting  the  TES-A  to  address  land  attack  targeting  from 
surface  ships.  They  initially  wanted  this  particular  ISR 
system  for  three  reasons:  to  leap  ahead  in  technology,  to 
lead  to  interoperability  and  software  sharing,  and  to  form 
a  long-term  relationship  with  the  Army.  (Lajoie,  Interview, 
2003  and  Read  Ahead  for  NFN) 

Around  this  time,  the  Chief  of  Naval  Reserves  and 
Chief  of  Naval  Operations  N6B  received  permission  to 
purchase  a  copy  of  the  TES-A  and  to  adapt  it  into  what  the 
Navy  called  the  Littoral  Surveillance  System  (LSS) .  (Read 
Ahead  for  NFN)  This  first  variant  of  TES-A,  the  LSS,  was 
made  up  of  TES-F  and  a  Mobile  Inshore  Undersea  Warfare 
System  Upgrade  (MIUW-SU) .  According  to  Littman: 

MIUW-SU  consists  of  a  Radar  Sonar  Surveillance 
Center  (RSSC)  van,  which  is  used  as  a  command 
center  and  an  array  of  sensors .  The  sensors 
include  radar  for  aircraft  detection  and  sonobuoy 
processing  for  underwater  target  detection.  This 
was  to  provide  complete  littoral  area 
surveillance.  (Littman,  2002,  p.  7) 

During  1998  through  2000,  the  LSS  was  built  and  tested 
in  Fleet  Battle  Experiment-Echo  (FBE-E) .  (Littman,  2002,  p. 
7) 

Later,  Navy  variants  of  the  TES-A  called  the  TES-N, 
Remote  Terminal  Components  (RTC)  and  Remote  Terminal 
Components  Lite,  were  developed  and  deployed  by  the  Navy. 
Each  variant  is  different,  and  used  for  different  levels  of 
activity.  Figure  2  depicts  the  three  variants  of  TES-N  used 
today . 
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Sensor  Servers 
-TES 


Remote  Servers 
-  RTC 


Client 

-RTC-LITEs 


Figure  2.  The  TES-N,  RTC,  and  RTC-Lite  (From:  Thomas, 
Joint  Fires  Network  Overview,  January  2003)  . 

The  Navy's  vision,  of  TES-N,  is  part  of  a  system  of  systems 
providing  an  end-to-end  architecture  for  Time  Sensitive 
Targeting  (TCT) .  However,  the  TES-N  is  only  one  component 
of  the  system  of  systems.  The  others  are  currently  JSIPS-N, 
GCCS-M  and  an  undetermined  fire  management  system 
generically  referred  to  as  Integrative  Cooperative 
Engagement  (ICE).  (Lajoie,  Interview,  2003)  In  naming  the 
TES-N,  RADM  Mullen  (now  VADM  selected  to  ADM),  as  N76, 
coined  the  TES-N  as  Naval  Fires  Network  (NFN) /TES-N  as  he 
was  preparing  his  Congressional  briefings.  This  later  was 
renamed  Joint  Fires  Network  (JFN) /TES-N.  (Burns,  2003) 


The  TES-N  is  a  complete  system,  and  is  equipped  with 
sensor  servers  which  allow  direct  connectivity  to  the 
sensor.  The  RTC  has  remote  servers  which  cannot  talk 
directly  to  the  sensors.  They  must  receive  the  sensor 
information  via  a  full  TES  or  some  other  intermediary,  but 
possess  full  processing  capability.  The  RTC-Lites  are 
basically  laptops/clients  that  are  only  used  for  visual 
display  of  information  in  the  fleet.  (Lajoie,  Interview, 
2003)  Figure  3  is  a  closer  view  of  the  Remote  Terminal 
Component  aboard  the  USS  Coronado. 


Figure  3.  Remote  Terminal  Component.  (From:  Littman, 

2002,  p.  52) . 

At  this  time,  the  Navy  realized  that  they  were 
deficient  in  the  TCT  of  NCW .  Therefore,  a  key  mission 
capability  that  the  Navy  was  trying  to  achieve  using  TES-N 
was  TCT.  Through  Fleet  Battle  Experiments  (FBE)  and  Limited 
Objective  Experiments  (LOE) ,  the  program  office  IWS  6C 
wanted  to  ensure  that  the  TES-N  provided  the  capability  to 
do  "Time  Critical  Targeting  against  rapidly  relocateable 
targets."  (NFN  Read  Ahead  for  N7  6)  The  goal  of  the  TES-N 
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was  to  be  able  "...  to  correlate  multiple  off  ship  sensors' 
data  and  intelligence  with  information  from  the  tactical, 
theater,  and  national  levels."  (Littman,  2002,  p.  41)  In 
the  end,  JFN/TES-N  would  be  able  to  collect  data  from  the 
sources  of  intelligence  listed  below  with  the  ability  for 
Cross-Intelligence  application  and  nodal  analysis. 

•  SIGINT 

•  National  data 

•  Real-time  interface 

•  Theater  SIGINT 

•  Modified  GALE 

•  Real-time  sensor  control  /  tasking 

•  Combat  assessment 

•  Imagery 

•  National  imagery 

•  Direct  Down  Link  (DDL)  theater  imagery 

•  COTS  package  for  exploitation 

•  Real-time  sensor  control/tasking 

•  Accurate  geo-location 

•  MTI 

•  Multiple  Theater  feeds  (e.g.  Global  Hawk) 

•  Auto  track  and  correlation 

•  Cross-cue/overlay  (Thomas,  Joint  Fires 
Network  Overview,  2003) 

Figure  4  shows  how  this  would  work. 
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Figure  4.  TES-N  Sensor  Inputs  (From:  Liftman,  2002,  p. 

42)  . 


Throughout  the  TES-N  development  and  fielding, 
Commander  3rd  Fleet  (C3F)  was  an  early  sponsor  and  made  an 
active  part  of  the  TES-N  lifecycle.  C3F  continually 
monitored  the  productivity  and  functionality  of  the  system. 
Later,  Third  Fleet  helped  to  conduct  FBE  and  LOE  to  improve 
TES-N  because  they  realized  it  would  help  with  operations 
such  as  land  attack  and  force  protection  in  the  fleet  . 
(Thomas,  Interview,  2003) 

In  2001,  the  TES-N  was  delivered  to  the  USS  Coronado. 
Installing  it  on  a  ship  brought  operational  insight  to  the 
system  engineers  developing  TES-N.  Due  to  the 
infrastructure  of  the  ship,  they  could  install  the  TES-N 
without  the  infrastructure  that  the  Army  had  used  with  TES- 
A.  Next,  when  the  TES-N  became  operable  on  ships,  the  Navy 
started  to  test  the  system  through  a  series  of  LOE. 
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Around  this  same  timeframe,  all  systems  of  the  TES 
(meaning  all  variants  of  TES-A  and  TES-N)  were  being  built 
with  an  open  and  common  architecture.  The  open  architecture 
of  TES  entails  a  common  standard  where  no  proprietary 
hardware  was  used.  It  was  all  either  government  owned  or 

commercial,  and  computer  components  were  required  to  be 
commercial  off  the  shelf.  This  was  done  so  that  it  would 

take  less  money  to  change  components  in  the  future  .  The 
common  architecture  of  the  TES  also  means  that  all  services 
use  a  common  software  version,  which  was  intended  to  mean 
that  there  was  a  core  version,  and  if  one  service  needed  a 

new  entity  for  the  core,  then  they  were  entitled  to  build 

it  to  fit  the  core  while  still  making  it  readily  available 
to  other  services  if  they  wanted  its  capability.  (Lajoie, 
Interview,  2003)  In  addition  each  service  was  funding  its 
individual  requirements,  but  all  services  got  to  benefit 
from  the  new  capabilities  added  to  the  core.  So  far,  this 
cost  sharing  arrangement  and  joint  configuration  management 
has  proven  to  be  very  beneficial.  (Burns,  2003)  Therefore, 
two  rules  were  that  no  service  could  change  the  core  and  no 
service  could  make  a  unilateral  change  if  it  affected  the 
core  or  hurt  another  service. 

Also  around  this  time,  the  United  States  Air  Force 
( USAF )  and  United  States  Marine  Corps  (USMC)  began  to 
acquire  variants  of  the  TES.  The  USMC  referred  to  it  as  the 
Tactical  Exploitation  Group  (TEG)  and  the  USAF  referred  to 
it  as  the  Intelligence,  Surveillance  and  Reconnaissance- 
Manager  (ISR-M) .  The  Marine  Corps,  like  the  Air  Force, 
realized  that  the  interoperability  of  the  system  was  a 
great  idea  because  they  would  benefit  from  the  sharing  of 
targets  and  ISR.  The  Marine  Corps  also  realized  that  to 
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obtain  this  capability,  they  only  had  to  evaluate  and 
update  their  system  called,  TEG.  (Lajoie,  Interview,  2003) 
Even  though,  TEG  and  ISR-M  have  the  same  functionality  as  a 
full  TES-N  or  TES-A  due  to  their  common  software  baseline, 
each  service  can  chose  doctrinally  to  use  the  system  to 
meet  their  specific  service  requirements  and  may  or  may  not 
take  advantage  of  all  the  inherent  tools  and  capabilities. 
The  common  software,  however,  allows  sharing  of  raw  and 
processed  sensor  data,  targeting  information,  and  other  ISR 
and  Intelligence  Preparation  of  the  Battlefield  (IPB) 
collaboration.  (Burns,  2003) 

Fortunately,  the  Army  in  1999  had  also  made  a  "virtual 
program  office"  for  the  development  of  the  TES  that 
included  all  the  services  called  the  Joint  Commonality 
Board  (JCB).  (Lajoie,  Interview,  2003)  The  Joint 
Commonality  Board  is  a  virtual  program  office  that  acts 
like  one  chain  of  command,  but  in  reality,  it  does  not 
function  that  way.  Ideally,  all  the  services  meet  with 
their  user  requirements  and  vet  out  which  requirements  are 
going  to  be  developed.  Yet,  each  service  is  answering  to 
their  respective  chain  of  commands  and  making  sure  that 
their  services  requirements  are  also  being  met.  From  the 
beginning,  all  services  were  on  board  but  only  the  Navy  and 
Army  were  contributing  money.  (Lajoie,  Interview,  2003) 
Since  the  TES-N  is  constructed  with  a  common  architecture, 
the  program  office  is  currently  working  on  Version  6.0  of 
the  software  and  has  fielded  some  of  these  TES  systems  seen 
below  in  Figure  5. 
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Figure  5.  Fielded  TES  Systems  (From:  Thomas,  Joint 

Fires  Network  Overview,  January  2003) . 


As  for  its  hardware  technology,  since  Moore's  law  states 
that  the  computing  power  of  a  computer  will  double  every  18 
months,  the  TES-N  will  continue  to  be  updated  each  year  to 
keep  up  with  hardware  changes.  The  TES-N  will  also  be 
updated  to  changes  in  user's  needs.  Below  is  a  figure  of 
what  the  TES-N  program  office  (IWS  6C)  hopes  to  accomplish 
in  2003.  This  list  is  more  specific  to  the  Navy's  needs  but 
there  are  also  requirements  that  the  Army,  USMC,  and  USAF 
hope  to  accomplish. 
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PMS  454  P3I  activity  in  2003 


•  AMSTE II  Integration 

•  JTAAC  integration 

•  ADOCS/AFATDS  Integration 

•  Tactical  Control  System 

•  NCCT  Integration 

•  SIGINT  Targeting 

•  CADP  Development 

•  Classified  Sensor  Integration 

•  RTC  Lite  Development 

•  Tactical  Dissemination  Module 

•  Improved  Networking 

•  Force  Protection  Package 


Fire  Control  &  Weapon  Quality  MTI 
Adaptation  of  AADC  Functionality  for  Land  Attack 
Engagement  Grid  Interface 
Integration  of  Common  UAV  Control  System 
Airborne  Sensor  Networking  (EP-3,  EA-6B,  RJ,  etc.) 
Fire  Control/Weapon  Quality  SIGINT  Geo -location 
X,  Ku  Phased  Array  Antenna  Development 
Classified  (2  Different  Sensors) 

Windows  based  TES  data  access  and  Display 
Move  Aircraft  uplink  from  LOS  to  Link  16  to  IP 
Improve  TES  Networking  &  DB  replication 
Integration  of  Force  Protection  Sensors 


Figure  6.  PMS  454  P3I  Activity  in  2003  (From:  Thomas, 

Joint  Fires  Network  Overview,  January  2003)  . 

B.  THE  SIX  LAYER  PICTURE  OF  THE  TES-N 

In  order  to  understand  the  composite  picture  of  the 
TES-N,  one  must  understand  the  TES-N' s  six-layer  picture. 

TES-N  creates  a  composite  picture  for  the 
tactical  war  fighter  by  stacking  all  of  its 
inputted  data  in  a  logical  way.  Essentially,  six 
different  layers  make  up  the  composite  picture 
This  stack. ..is  built  by  combining  the  data  from 
the  many  sources  including:  electronic 

maps/charts,  tactical  and  national  imagery 
(IMINT),  Moving  Target  Indicator  (MTI)  and  track 
data  from  airborne  sensors,  signals  intelligence 
(SIGINT)  both  from  the  Miniaturized  Data 
Acquisition  System  (MIDAS)  and  from  the  global 
broadcast  system  (GBS) ,  graphical  data,  and 
imagery  interpretation  reports  (HR).  TES-N  can 
then  display  the  composite  data  in  various  ways 
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that  can  support  the  myriad  missions  today' s 
warfighters  find  themselves  in.  (Littman,  2002, 
p.  40) 


Figure  7 . 


Stacked  Information  Layers 
2002,  p.  43) . 


(From:  Littman, 


The  TES-N  architecture  is  made  up  of  six  layers,  each 
possessing  different  functions .  More  specifically,  the 
first  or  base  layer  is  composed  of  maps  so  that  the  system 
can  obtain  latitudes  and  longitudes  for  its  targets  and 
intelligence  data.  The  digital  maps,  which  can  be  updated 
as  needed,  are  taken  from  the  National  Imagery  and  Mapping 
Agency  (NIMA)  .  Layer  2  is  made  up  of  tactical  and  national 
imagery.  Tactical  imagery  comes  from  numerous  air  and 
ground  sensors  such  as  F-18's  and  UAV's.  Layer  3  ..."is 

composed  of  Moving  Target  Indicator  (MTI)  and  other  track 
data  sent  to  TES-N  from  a  [capable]  aircraft."  (Littman, 
2002,  p.  48,  The  word  capable  is  not  in  the  quote)  The 
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fourth  layer  receives  signals  intelligence  from  sources 
such  as  National  SIGINT,  SCI  level  SIGINT,  and  SIGINT  from 
the  Miniaturized  Data  Acquisition  System  (MIDAS) .  The  fifth 
layer  is  made  up  of  the  Graphical  Situation  Display  (GSD)  , 
which  helps  improve  the  asset  organization  and  the 
commander's  situational  awareness.  The  sixth  layer's 
Imagery  Interpretation  Reports  (HR)  further  improves  the 
commander's  situational  awareness  and  asset  organization. 
"All  six  of  the  layers'  functionalities  can  be  toggled  on 
or  off  by  the  operators  to  produce  the  most  relevant 
picture  for  a  given  situation."  (Littman,  2002,  p.  50) 
Finally,  to  locate  information,  an  operator  has  flexibility 
within  each  layer  by  being  able  to  scale  in  or  out  for  the 
data  required. 

C.  HOW  THE  JFN/TES— N  WORKS 

The  JFN/TES-N  is  a  joint  end-to-end  architecture  for 
Time  Sensitive  Targeting.  The  system  merges  the 
capabilities  from  ISR,  targeting,  mission  planning,  and 
situational  awareness  in  order  to  strike  an  accurate 
target.  As  seen  in  Figure  8  below,  the  TES-N  first  detects, 
collects  and  displays  the  data  from  sensors  and  data  links 
in  real  time .  This  data  is  then  exploited  using  its 
intelligence  subsystems  so  that  commanders  can  make  real 
time,  accurate  decisions  about  targets.  These  targets  are 
assigned  to  different  weapons  systems  so  that  they  can  be 
attacked.  (Blackledge,  2002,  p.  5) 
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Joint  Fires  Network  Provides... 


Classified  Direct  Direct  Direct  SATCOM  Direct  Direct  Direct  Direct  Direct 


. . .  From  National  and  Theater  Off  board  Assets 


*  Note  -  IOC  SUMMER  03 


Figure  8  .  A  Picture  of  What  JFN  Provides  to  the  User 

(From:  Thomas,  Joint  Fires  Network  Overview,  2003)  . 
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III.  THE  TRADITIONAL  (AS  DESCRIBED  BY  THE  5000 
SERIES  PUBLICATIONS)  APPROACH  TO  ACQUISITION 


This  chapter  provides  the  reader  with  an  understanding 
of  the  acquisition  process  and  policy  that  has  been 
developed  over  the  past  fifty  plus  years  .  Readers  need  to 
understand  the  old  process  to  better  understand  the  changes 
and  why  these  changes  are  being  made. 

Since  before  the  cold  war,  DoD's  systems  acquisition 
has  been  following  a  policy  that  prescribes  a  phased 
process  for  developing  a  system.  This  process  follows  a 
path  of  finishing  one  activity,  obtaining  approval  and  then 
proceeding  to  the  next  activity.  Each  year  the  DoD  also  has 
an  established  way  of  submitting  a  budget  so  that  they  can 
allocate  obligation  authority  to  each  program  accordingly. 
Furthermore,  there  is  a  policy  for  conducting  tests  and 
evaluations  for  programs.  The  phased  process  is  a  formal 
and  organized  way  of  acquiring  systems,  which  has  been 
used,  evolved,  and  tailored  for  over  fifty  years,  but  due 
to  rapidly  changing  technology,  many  believe  that  this 
acquisition  policy  is  performed  in  an  inefficient  way  that 
produces  outdated  results .  Some  key  points  I  hope  to 
highlight  in  this  chapter  are  that  the  "traditional" 
process  is  accomplished  in  phases  and  milestones,  it  must 
have  an  Operational  Requirements  Document  (ORD)  and  Mission 
Needs  Statement  (MNS ) ,  and  policies  such  as  budgetary 
submissions  and  test  and  evaluation  are  developed  according 
to  this  old  policy. 
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A.  THE  DODI  5000.2  ACQUISITION  PROCESS 

According  to  DoDI  5000. 2,  Operation  of  the  Defense 
Acquisition  System,  an  acquisition  program  is: 

A  directed,  funded  effort  designed  to  provide  a 
new,  improved,  or  continuing  materiel,  weapon,  or 
information  system  or  service  capability  in 
response  to  a  validated  operational  or  business 
need.  Acquisition  programs  are  divided  into 
different  categories  that  are  established  to 
facilitate  decentralized  decision-making, 
execution,  and  compliance  with  statutory 
requirements  .  Technology  projects  are  not 
acquisition  programs  .  (Defense  Acquisition  Desk 
Book  Site,  DODI  5000.2  Operation  of  the  Defense 
Acquisition  System,  Enclosure  E2.1.2) 

The  Defense  Acquisition  System  consists  of  a  series  of 
phases  and  control  gates  which  control  the  development  of  a 
new  program  by  balancing  the  risks  and  benefits  while 
controlling  the  costs  of  that  system.  DoDI  5000.2 
establishes  the  Defense  Acquisition  System  as  a  process, 
which  translates  a  user' s  Mission  Needs  Statement  and 
business  requirements,  and  the  latest  technology 
capabilities  into  a  system  that  is  useful  for  the  user.  A 
model  of  a  defense  acquisition  management  program  is  shown 
below.  It  is  broken  down  into  three  activities  called  Pre- 
Systems  Acquisition,  Systems  Acquisition,  and  Sustainment. 
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Figure  9.  The  5000  Model  (From:  Defense  Acquisition 

Desk  Book  Site,  DODI  5000.2  Operation  of  the  Defense 

Acquisition  System) . 


These  three  activities  are  then  further  divided  into 
four  more  phases,  the  first  and  third  activity  having  one 
phase  and  the  second  activity  having  two  phases  .  For 
example,  the  first  phase  is  Concept  and  Technology 
Development.  Next,  each  phase  is  divided  into  the  specific 
work  efforts  achieved  in  that  phase  .  For  example,  the  work 
efforts  in  the  Concept  and  Technology  Development  phase  are 
Concept  Exploration  and  Component  Advanced  Development. 
These  are  described  below.  Each  phase  also  has  entrance  and 
exit  criteria,  which  establish  whether  the  project  is  ready 
to  enter  or  exit  its  future  or  existing  phase  respectively. 
Entrance  criteria  for  a  phase  are  the  minimum 
accomplishments  that  must  be  completed  by  a  program  before 
it  is  allowed  to  enter  the  next  phase  .  Similarly,  exit 
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criteria  are  defined  as  program  specific  results  that  must 
be  reached  by  the  end  of  the  phase.  In  addition,  there  are 
three  important  milestones  in  the  overall  process.  The 
program  office  must  ensure  that  there  is  an  approved  MNS  in 
order  to  start  the  program  at  Milestone  A,  which  happens 
before  Concept  Exploration.  To  pass  Milestone  B,  which 
occurs  right  before  Systems  Integration,  they  must  ensure 
they  have  an  approved  ORD  .  In  order  to  proceed  past 
Milestone  C,  which  is  right  before  the  work  effort  known  as 
Low-Rate  Initial  Production,  the  system  must  be  approved 
for  low  rate  initial  production  by  the  correct  approving 
authority . 

B.  THE  DESCRIPTION  OF  THE  DODI  5000.2  MODEL 

During  the  Pre-Systems  Acquisition  action,  which  is 
also  known  as  the  Concept  and  Technology  phase,  the  key 
objectives  are  to  ascertain  user  requirements  and  the 
technological  opportunities  that  are  available  for  the  new 
system.  This  phase  is  divided  into  work  efforts  called 
Concept  Exploration  and  Component  Advanced  Development  (as 
seen  below) . 

In  the  Concept  Exploration  stage,  the  program  office 
conducts  paper  studies  of  alternative  concepts  for  meeting 
the  user  requirements  listed  in  the  MNS.  The  exit  criterion 
for  Concept  Exploration  is  that  the  program  office  realizes 
that  they  have  a  specific  concept  that  can  be  developed 
with  existing  technology.  The  program  office  enters  the 
Component  Advanced  Development  stage  to  start  the  system' s 
architecture  once  they  are  sure  the  concept  is  sound.  In 
this  stage,  the  engineers  continually  study  concepts  that 
might  be  helpful  to  further  technological  advancement  of 
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this  system.  In  order  for  the  program  to  proceed  to  the 
next  phase,  it  is  necessary  to  demonstrate  that  the  system 
architecture  and  technology  of  the  system  are  in  their 
relevant  environments  as  described  by  the  MNS . 


Concept  and  Technology  Development 
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Figure  10.  Concept  and  Technology  Development  Work 

Content  (From:  Defense  Acquisition  Desk  Book  Site, 
DODI  5000.2  Operation  of  the  Defense  Acquisition 

System) . 

The  next  activity  is  the  Systems  Acquisition  Activity, 
which  occurs  across  both  the  System  Development  and 
Demonstration  Phase  and  the  Production  and  Deployment 
Phase.  DoDI  5000.2,  Operation  of  the  Defense  Acquisition 
System,  states  that: 

The  purpose  of  the  System  Development  and 
Demonstration  phase  is  to  develop  a  system, 
reduce  program  risk,  ensure  operational 
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supportability ,  design  for  producibility ,  ensure 
affordability,  ensure  protection  of  Critical 
Program  Information,  and  demonstrate  system 
integration,  interoperability,  and  utility. 
Discovery  and  development  are  aided  by  the  use  of 
simulation-based  acquisition  and  test  and 


evaluation  and  guided  by  a  system  acquisition 
strategy  and  test  and  evaluation  master  plan 
(TEMP).  System  modeling,  simulation,  test,  and 
evaluation  activities  shall  be  integrated  into  an 
efficient  continuum  planned  and  executed  by  a 
test  and  evaluation  integrated  product  team  (T&E 
IPT)  .  (Defense  Acquisition  Desk  Book  Site,  DODI 
5000.2  Operation  of  the  Defense  Acquisition 
System,  4 . 7 . 3 . 2 . 1 . 1 ) 

The  System  Development  and  Demonstration  Phase  is 
divided  into  two  system  work  efforts:  Systems  Integration 
and  Systems  Demonstration  (as  seen  below) . 
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Figure  11.  System  Development  and  Demonstration  Work 


Content  (From:  Defense  Acquisition  Desk  Book  Site, 
DODI  5000.2  Operation  of  the  Defense  Acquisition 

System) . 
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In  Systems  Integration,  the  program  office 
concentrates  on  the  integration  of  subsystems  and  the 
cutback  of  integration  risk.  In  order  to  enter  into  Systems 
Demonstration,  the  prototypes  developed  in  System 
Integration  must  be  functioning  in  a  relevant  environment. 
During  Systems  Demonstration,  the  systems  engineers  and 
contractors  complete  development,  demonstrate  engineering 
development  models ,  and  conduct  combined  developmental  and 
operational  testing.  The  program  may  exit  this  phase  and 
enter  the  Production  and  Deployment  activity  only  after 
sufficient  testing  and  a  successful  system  demonstration  in 
its  intended  environment. 


In  the  Production  and  Deployment  Phase,  the  program 
office  hopes  to  establish  an  operational  capability  that 
was  requested  earlier  through  the  MNS  .  This  phase  is  also 
further  divided  into  two  parts:  Low-Rate  Initial  Production 
and  Full-Rate  Production  and  Deployment  (as  seen  below) . 
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Figure  12  .  Production  and  Deployment  Work  Content 

(From:  Defense  Acquisition  Desk  Book  Site,  DODI  5000.2 
Operation  of  the  Defense  Acquisition  System) . 
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In  order  for  a  program  to  start  Low-Rate  Initial 
Production,  the  program  must  obtain  approval  from  the 
Milestone  Decision  Authority  (MDA)  (discussed  below) .  This 
will  ensure  that  the  program  office  has  completed  a  list  of 
requirements  such  as  an  approved  ORD,  acceptable 
interoperability ,  suitable  operational  support abil it y , 
demonstration  that  the  system  is  affordable  throughout  the 
life  cycle,  adequate  information  assurance  to  include 
information  assurance  detection  and  recovery,  and  up  to 
standard  anti-tamper  provisions.  During  Low-Rate  Initial 


Production, 

not 

only  is 

the 

system 

going  through 

low-rate 

production. 

but 

it  also 

has 

a  set 

of  tests  that 

it  must 

pass,  such 

as 

initial 

operational 

test  and  evaluation 

(IOT&E)  and  live  fire  test  and  evaluation  (LFT&E)  .  It  also 
must  be  established  whether  the  system  is  ready  for  full- 
rate  production  (FRP).  Once  the  system  has  been  deemed 
operationally  effective  by  the  Operational  Test  and 


Evaluation 

Force  (OPTEVFOR)  and 

ready 

for 

full-rate 

production 

,  it  is  then 

allowed  to 

enter 

the 

Full-Rate 

Production 

and  Deployment 

stage.  In  order 

to 

exit  this 

activity. 

the  system  must 

have  full 

operational 

capability 

and  the  deployment  must  be  complete. 

Finally,  the  purpose  of  the  last  activity,  entitled 
Sustainment,  is  to  provide  affordable  support  of  the  system 
throughout  its  life  cycle  .  This  activity  is  called  the 
Operations  and  Support  Phase  and  is  also  divided  into  two 
parts:  Sustainment  and  Disposal  (as  seen  below). 
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Figure  13.  Operations  and  Support  Work  Content  (From: 

Defense  Acquisition  Desk  Book  Site,  DODI  5000.2 
Operation  of  the  Defense  Acquisition  System) . 


In  the  first  part,  the  work  effort  is  concentrated  on 
operational  support  and  in  the  latter;  it  focuses  on 
disposal  or  demilitarization  of  the  system.  For  the 
purposes  of  this  thesis,  the  description  of  the  5000.2 
model,  which  is  the  baseline  for  "traditional"  acquisition, 
is  complete. 

C.  CATEGORIES  OF  ACQUISITION  POLICY 

There  are  three  different  acquisition  categories  in 
the  "traditional"  process  of  acquisition  as  explained  by 
the  5000  series  documents .  The  process  which  each  program 
follows  depends  on  the  specific  acquisition  category  in 
which  it  is  placed.  The  different  acquisition  categories  in 
order  from  largest/most  complex  to  smallest/simplest,  are 
Acquisition  Category  I,  (ACAT  I),  Acquisition  Category  II 
(ACAT  II),  and  Acquisition  Category  III  (ACAT  III)  .  Each 
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category  has  requirements,  which  the  program  office  must 
meet  and  obtain  approval  for  before  they  proceed  to  the 

next  activity  in  the  "traditional"  process  .  In  addition, 
all  acquisition  programs  should  have  a  MDA;  of  course,  the 
rank  and  position  of  the  MDA  varies  according  to  ACAT  . 
Therefore,  each  program  is  mapped  into  one  of  three 

categories,  where  they  follow  similar  regulations  but  at 
varying  degrees  of  authority. 

D.  OBLIGATION  AUTHORITY 

Finally,  the  way  in  which  obligation  authority  is 
allocated  for  each  system  development  is  directly  linked  to 
the  "traditional"  process  of  acquisition  as  described  by 
the  5000  series  publications.  Right  now  the  DoD  uses  a 

system  called  The  Planning,  Programming,  and  Budgeting 
System  (PPBS) ,  whose  purpose  "is  to  provide  the  optimal  mix 
of  forces,  equipment,  and  support,  which  can  be  achieved 
within  fiscal  restraints."  (AFMC  Financial  Management 
Handbook,  Updated  December  2001)  The  PPBS  is  a  plan  for 

developing  DoD's  budget  request,  which  is  sent  to  the 
president  for  approval  and  made  a  part  of  the  President's 
Budget  that  is  sent  to  Congress.  Within  the  PPBS: 

the  odd-numbered  calendar  years  are  used  to 
concentrate  on  the  DoD  planning  process.  During 
the  even-numbered  years,  the  Services  formulate 
and  submit  their  Program  Objective  Memorandum 
(POM)  and  BES  (Budget  Estimate  Submissions)  to 
the  OSD  (Office  of  the  Secretary  of  Defense) .  The 
PPBS  is  a  continuous  process  with  PPBS  activities 
from  one  year  overlapping  with  PPBS  activities 
applicable  to  other  years  .  (AFMC  Financial 
Management  Handbook,  Updated  December  2001) 
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Congress  knows  how  much  obligation  authority  the 
program  office  desires  for  each  system  based  on  these 
submissions,  and  then  later  decides  how  much  they  are 
willing  to  appropriate  for  each  program.  Congress  knows  the 
desires  of  the  program  office  since  each  service  has  stated 
the  amount  of  obligation  authority  needed  and  its  purpose 
in  their  POM  and  BES  .  This  process  is  efficient  for  the 
phased  process  described  by  the  5000  series  documents,  but 
for  Evolutionary  Acquisition  following  a  Spiral  Development 
this  would  not  be  effective  since  Program  Managers  do  not 
know  the  purpose  of  their  obligation  authority  so  far  in 
advance . 

This  acquisition  policy  has  been  followed  since  before 
the  Cold  War.  It  is  a  phased  process  consisting  of  a  series 
of  phases  and  control  gates,  which  control  the  development 
of  a  new  program  by  balancing  the  risks,  costs,  and 
benefits  of  that  system.  This  process  also  follows 
budgetary  rules  set  up  by  the  DOD's  PPBS  .  This  acquisition 
policy,  along  with  other  budgetary  and  testing  policies, 
are  considered  outdated  processes  which  need  to  be  changed 
so  that  changes  in  today' s  technology  can  be  more 
effectively  tracked . 
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IV.  EVOLUTIONARY  ACQUISITION  FOLLOWING  A  SPIRAL 

DEVELOPMENT 


A.  THE  SPIRAL  PROCESS  DEFINITION 

The  goal  of  this  chapter  is  to  provide  the  reader  with 
a  clear  understanding  of  Evolutionary  Acquisition  following 
a  Spiral  Development. 

As  can  be  seen,  the  phased  process  described  in  the 
Department  of  Defense  5000.2  directive  draws  system 
development  and  acquisition  out  over  a  long  period  of  time  . 
Unf ortunately,  developments  with  this  phased  process  might 
not  be  ready  for  use  until  several  years  later.  This  is 
disadvantageous  to  the  United  States  especially  when 
dealing  with  C4I  systems  since  information  technology  is 
changing  so  rapidly.  Therefore,  the  DoD  acquisition  policy 
needs  to  produce  higher  performance,  with  a  more  rapid 
deployment  of  the  system.  The  acquisition  policy  that  has 
been  in  use  since  before  the  Cold  War  needs  to  be  changed. 
Some  major  goals  of  this  new  process  would  be  to  lessen  the 
restrictiveness  used  in  the  policy  by  giving  more  flexible 
decision  authority  to  the  program  manager.  (Evolution  of 
the  DOD  Acquisition  Process:  In  a  Nutshell) 

Most  of  these  changes  were  enacted  on  October  30, 
2002,  when  Deputy  Defense  Secretary  the  Honorable  Paul 
Wolfowitz  signed  guidance  that  gave  relief  from  some  of  the 
current  policies  outlined  in  documents  such  as:  DOD 
Directive  5000.1,  "The  Defense  Acquisition  System";  DOD 
Instruction  5000.2,  "The  Operation  of  the  Defense 
Acquisition  System";  and  DOD  5000. 2-R,  "Mandatory 
Procedures  for  Major  Defense  Acquisition  Programs  and  Major 
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Automated  Information  System  Acquisition  Programs."  Deputy 
Defense  Secretary  Wolfowitz  wrote  that  "the  intent  of  the 
guidance  is  to  rapidly  deliver  affordable,  sustainable 
capability  to  the  warfighter  that  meets  the  warfighter’s 
needs."  (Plummer,  2002)  The  Honorable  Mr.  Wolfowitz 
continued  to  say  that  this  new  policy  would  hopefully 
create  an  environment  in  the  acquisition  community  that 
would  encourage  "efficiency,  flexibility,  creativity  and 
innovation."  The  hope  of  this  new  directive  was  to  give 
program  offices  the  freedom  to  streamline  their  programs  as 
they  saw  fit.  Yet,  he  still  hoped  that  they  would  develop 
systems  whose  standards  were  just  as  high.  (Plummer,  2002) 

The  type  of  acquisition  that  the  Honorable  Mr. 
Wolfowitz  promoted  is  Evolutionary  Acquisition  following  a 
Spiral  Development.  According  to  the  Department  of  Defense: 

Evolutionary  acquisition  is  DoD' s  preferred 
strategy  for  rapid  acquisition  of  mature 
technology  for  the  user.  An  evolutionary 
approach  delivers  capability  in  increments, 
recognizing,  up  front,  the  need  for  future 
capability  improvements.  The  success  of  the 
strategy  depends  on  the  consistent  and  continuous 
definition  of  requirements  and  the  maturation  of 
technologies  that  lead  to  disciplined  development 
and  production  of  systems  that  provide  increasing 
capability  towards  a  materiel  concept. 

(http : //dod5000 . dau ,mil/Memo500020ct30 .doc) 

Evolutionary  Acquisition  following  a  Spiral 
Development  is  completely  different  .  It  cannot  be  carried 
out  following  the  "traditional"  acquisition  process  as 
described  by  the  5000  series  documents.  It  needs  to  follow 
a  spiral  process,  a  process  where: 

...a  desired  capability  is  identified,  but  the  end- 
state  requirements  are  not  known  at  program 
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initiation.  Those  requirements  are  refined 
through  demonstration  and  risk  management;  there 
is  continuous  user  feedback;  and  each  increment 
provides  the  user  the  best  possible  capability. 

The  requirements  for  future  increments  depend  on 
feedback  from  users  and  technology  maturation . 

(http : //dod5000 . dau .mil/Memo500020ct30 .doc) 

This  Evolutionary  Acquisition  following  a  Spiral 
Development  can  be  viewed  below.  The  figure  tries  to  depict 
that  there  is  an  initial  desired  capability  but  the  end 
product  is  not  known .  It  further  emphasizes  that  at  the  end 
of  each  spiral  user  feedback  is  analyzed  along  with  changes 
in  technology  to  produce  new  requirements  for  the  next 
spiral.  This  process  happens  faster  than  the  "traditional" 
process  as  described  by  the  5000  series  documents  and 
produces  a  product  to  the  fleet  at  the  end  of  each  spiral. 


Etti'piin  fcf-hlOTffl 


Figure  14.  A  Figure  Depicting  Evolutionary  Acquisition 

following  a  Spiral  Development  (From: 
http : //dod5000 . dau .mil/Memo500020ct30 .doc) . 
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B.  EVOLUTIONARY  ACQUISITION  FOLLOWING  A  SPIRAL  PROCESS 

A  literature  search  of  articles  and  doctrine  on 
Evolutionary  Acquisition  following  a  Spiral  Development 
such  as  DoD  doctrine  from  memos  entitled  Operation  of  the 
Defense  Acquisition  System,  and  articles  by  Dr.  Stuart 
Starr,  The  Requirements  Process  for  the  Acquisition  of 
Command  and  Control  Systems :  Needs,  shortfalls ,  and 
Challenges ,  and  the  article,  Assessing  Military  Information 
Systems T  revealed  COL  Wayne  M.  Johnson,  USAF  (Ret)  and  Carl 
0.  Johnson's  breakdown  of  Evolutionary  Acquisition 
following  a  Spiral  Development  in  their  article,  The 
Promise  and  Perils  of  Spiral  Acquisition:  A  Practical 
Approach  to  Evolutionary  Acquisition ,  to  be  most  helpful 
and  accurate. 

There  are  key  facts  of  the  Evolutionary  Acquisition 
following  a  Spiral  Development  that  a  program  office  must 
know  and  consider  before  adopting  it  into  their  program. 
One  must  first  realize  that  Evolutionary  Acquisition 
following  a  Spiral  Development  will  not  work  for  all 
programs.  In  my  opinion  the  "traditional"  approach  as 
described  by  the  5000  series  documents  would  be  better  for 
larger/  more  complex  programs.  There  are  specific 
characteristics ,  which  Evolutionary  Acquisition  following  a 
Spiral  Development  is  appropriate.  For  example,  Johnson  and 
Johnson  state: 
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The  intended  spiral  acquisition  characteristics 
are  large  proportion  of  commercial  technology  or 
previously  developed  military  technology;  a 
desire  to  shorten  technology  insertion  life 
cycles;  schedule  urgency;  flexibility  in 
requirements  for  later  insertions  and  budgetary 
uncertainty.  (Johnson  and  Johnson,  Summer  2002, 
p.  177) 

Also,  unlike  the  phased  approach  explained  earlier, 
the  program  office  using  Evolutionary  Acquisition  following 
a  Spiral  Development  usually  has  an  end  goal  but  each 
spiral  is  not  completely  developed  beforehand,  and 
therefore,  not  preplanned  until  the  next  spiral.  This  means 
that  the  program  office  can  only  determine  what  needs  to  be 
accomplished  in  the  next  spiral  by  determining  what  was 
finished  effectively  in  the  current  spiral.  Thus,  the  main 
goal  of  the  Evolutionary  Acquisition  following  a  Spiral 
Development  is  developing  a  series  of  smaller  projects, 
which  in  turn,  are  returned  to  the  user  more  rapidly. 

Johnson  and  Johnson  then  break  up  the  Evolutionary 
Acquisition  following  a  Spiral  Development  into  three  main 
components,  which  can  be  summarized  under  the  titles 
Requirements  Definition,  Acquisition  Strategy,  and 
Employment  Concept.  These  three  components  help  define  what 
is  needed  for  a  spiral. 

1 .  Requirements  Definition 

For  the  Requirements  Definition  component  of  this  new 
approach,  Johnson  and  Johnson  state,  "the  user  has  to  be 
involved  up  front  and  understand  the  desired  end  state 
solution  will  not  come  with  the  first  delivery."  (Johnson 
and  Johnson,  Summer  2002,  p.  178)  Next,  the  program  must 
have  a  way  of  doing  business  that  includes  the  user  in  each 
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increment  of  the  spiral.  This  means  that  the  user  must  help 
determine  at  each  spiral  what  the  program  needs  and  then 
there  must  be  a  process  through  which  the  program  office 
and  the  user  both  decide  on  what  is  essential  for  the  next 
spiral  of  the  project.  Thus,  continuous  communication, 
trust,  teamwork  and  regularly  held  meetings  are  essential 
for  obtaining  the  correct  requirements  and  achieving 
success  within  each  spiral.  The  system  requirements  are 
stated  in  a  document  that  resembles  an  ORD  from  the 
"traditional"  5000  series  approach,  but  it  is  called  a 
Spiral  Requirements  Document  (SRD)  instead.  This  document 
lists  the  user' s  essential  requirements  for  the  system,  but 
the  users  also  have  an  understanding  that  the  system  might 
be  less  than  perfect  or  80%  effective  .  The  users  "...  will 
test  it,  field  it,  and  use  it  knowing  it  does  not  meet  all 
their  needs,  but  it  does  have  operational  utility." 
(Johnson  and  Johnson,  Summer  2002,  p.  179)  Therefore,  there 
must  be  flexibility  and  balance  between  the  users  and  the 
program  office  to  establish  the  requirements.  One  can 
already  see  the  three  main  differences  between  the  5000 
series  approach.  "First,  in  a  [Evolutionary  Acquisition 
following  a]  Spiral  [Development]  ...the  program  developer 
may  make  improvements  that  do  not  readily  seem  to  support 
the  end  goal."  (Johnson  and  Johnson,  Summer  2002,  p.  180, 
the  words  Evolutionary  Acquisition  following  a  and 
Development  are  not  in  the  quote)  Next,  the  Evolutionary 
Acquisition  following  a  Spiral  Development  allows  for  the 
developer  to  more  easily  put  leading  edge  software  into  the 
system.  Lastly,  in  Evolutionary  Acquisition  following  a 
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Spiral  Development,  at  the  end  of  each  spiral,  the  item  is 
not  considered  to  be  complete.  Instead,  another  spiral  will 
be  used  to  produce  an  upgrade  quickly. 

2 .  Acquisition  Strategy 

Next,  the  program  office  must  develop  an  Acquisition 
Strategy,  which  is  a  framework  for  translating  the 
requirements  into  actions .  For  this  strategy,  the  program 
office  needs  to  develop  constant  communication  and  teamwork 
with  the  users,  developers,  Spiral  Development  Integrated 
Product  Teams,  and  the  Program  Office.  This  includes 
scheduled  meetings  of  a  Spiral  Development  Integrated 
Product  Team.  This  team  will  help  the  program  office 
provide  insight  to  the  user. 

Flexibility  like  in  the  phased  approach  is  also 
important  in  the  Acquisition  Strategy.  First,  the  program 
manager  must  look  for  long-term  flexibility  in  the  project, 
and  must  realize  that  appropriations  from  Congress  can 
change,  and  therefore,  must  be  willing  to  accept  budget 
cuts  .  A  solution  for  budget  cuts  for  Evolutionary 
Acquisition  following  a  Spiral  Development  that  cannot  be 
done  in  the  phased  approach  would  be  to  move  a  requirement 
from  one  spiral  to  the  next .  Another  difference  between  the 
phased  approach  and  Evolutionary  Acquisition  following  a 
Spiral  Development  is  that  flexibility  in  testing  must  also 
exist.  "The  testing  community  cannot  become  rigidly  fixed 
on  an  end  requirement  or  a  [Evolutionary  Acquisition 
following  a]  Spiral  Development  will  not  work."  (Johnson 
and  Johnson,  Summer  2002,  p.  181,  the  words  Evolutionary 
Acquisition  following  a  are  not  in  the  quote)  Therefore, 
testing  procedures  need  to  be  assessed  so  that  user  is 
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still  getting  a  safe  product  but  with  the  understanding 
that  more  testing  is  needed  before  there  will  be  an  end 
result.  In  Evolutionary  Acquisition  following  a  Spiral 
Development,  one  must  also  learn  how  to  manage  risk  by  not 
allowing  the  burden  of  success  to  be  based  on  too  much 
technology  or  capability  in  one  spiral  at  a  time. 
Therefore,  Johnson  and  Johnson  recommend  breaking  up  the 
development  into  smaller  compartments.  In  other  words, 
"keep  the  critical  path  simple  and  singular."  (Johnson  and 
Johnson,  Summer  2002,  p.  181) 

3 .  Employment  Concept 

The  Employment  Concept  component  of  Evolutionary 
Acquisition  following  a  Spiral  Development  can  be  a  little 
more  challenging  than  the  approach  described  by  the  5000 
series  documents,  but  the  output  is  produced  more  quickly. 
In  this  part  of  Evolutionary  Acquisition  following  a  Spiral 
Development,  the  user  must  work  directly  with  the  program 
office  and  testers  to  determine  "...the  priority  list  of 
capabilities  they  would  like  to  see  fielded.  This  gives  the 
program  office  a  means  to  make  focused  decisions."  (Johnson 
and  Johnson,  Summer  2002,  p.  183)  This  is  more  challenging 
in  Evolutionary  Acquisition  following  a  Spiral  Development 
because  the  Program  office  is  continuously  getting  new  user 
requirements  and  then  making  sure  that  the  testers  and 
engineers  know  and  agree  with  these  requirements.  The 
challenge  is  that  these  requirements  are  constantly 
changing  as  opposed  to  the  phased  approach  were  once  the 
requirements  are  composed  they  do  not  usually  change  as 
rapidly . 
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The  logistics  team  during  Evolutionary  Acquisition 
following  a  Spiral  Development  must  be  very  skilled  because 
there  are  usually  multiple  configurations  of  the  system 
fielded  at  the  same  time.  The  multiple  configurations  of 
the  system  are  disadvantageous ,  but  this  happens  today  with 
the  5000  series  approach  due  to  unplanned  occurrences,  and 
in  the  spiral  approach,  the  program  office  is  doing  upfront 
planning  for  this  logistics  challenge  by  realizing  that 
with  each  spiral  there  is  a  different  system  produced. 
Therefore,  logistics  representatives  early  on  are  prepared 
for  different  configurations  of  the  same  development  making 
it  easier  for  maintenance  and  training. 

In  conclusion,  there  are  many  advantages  to 
Evolutionary  Acquisition  following  a  Spiral  Development  and 
some  disadvantages.  Some  advantages  over  the  traditional 
form  of  acquisition  are  that  capabilities  are  delivered 
quicker  to  the  warfighter,  the  program  office  can  manage 
risk  more  efficiently.  Evolutionary  Acquisition  following  a 
Spiral  Development  is  more  receptive  to  user  needs,  and 
technology  changes  can  be  applied  to  the  system  more 
easily.  Some  aspects  to  be  cautious  of  when  using 
Evolutionary  Acquisition  following  a  Spiral  Development  for 
their  program  are:  Evolutionary  Acquisition  following  a 
Spiral  Development  could  be  looked  at  as  an  easy  budget  cut 
by  Congress  due  to  its  flexibility  between  spirals,  test 
teams  must  realize  that  partial  capability  must  be  looked 
at  initially,  logistics  teams  must  be  willing  to  support 
multiple  configurations  that  are  fielded,  the  user  must 
understand  that  they  are  not  going  to  get  their  final 
product  in  the  first  spiral  but  probably  an  80%  effective 
system,  and  they  must  understand  that  their  program  will  be 
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subject  to  false  comparison.  "...  The  question  will  be,  'Why 
fund  the  new  system  that  does  not  greatly  perform  over  the 
older  system?'"  (Johnson  and  Johnson,  Summer  2002,  p.  186) 
Even  with  these  drawbacks  to  Evolutionary  Acquisition 
following  a  Spiral  Development,  the  benefits  in  the  long 
run  are  significant  for  many  programs. 

Evolutionary  Acquisition  following  a  Spiral 
Development  is  the  acquisition  policy  of  the  future  for 
most  systems  .  It  has  many  advantages  and  some 
disadvantages.  Overall  there  must  be  a  strong  relationship 

with  users,  contractors,  the  program  officer,  and  testers 
for  this  Evolutionary  Acquisition  following  a  Spiral 
Development  to  work. 
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V. 


THE  TES-N  ACQUISITION  PROCESS 


This  chapter  further  explains  why  the  United  States 
needs  to  change  its  acquisition  policy  in  order  to  provide 
timely  technology  and  intelligence  to  the  warfighter.  Next, 
it  explains  the  JFN/TES-N  Evolutionary  Acquisition 
following  a  Spiral  Development  process.  This  chapter  then 
uses  the  breakdown  of  Evolutionary  Acquisition  following  a 
Spiral  Development  in  the  Johnson  and  Johnson  article  as  a 
model  for  Evolutionary  Acquisition  following  a  Spiral 
Development  and  the  DoD  5000  series  documents  as  a  model 
for  the  "traditional"  acquisition  policy.  These  models  are 
then  compared  to  reveal  key  points  that  highlight  relative 
differences  between  the  two,  and  these  differences  serve  as 
a  basis  for  characterizing  the  JFN/TES-N  acquisition 
process . 

A.  TIMELY  INTELLIGENCE  AND  SUCCESS  IN  WARFARE 

History  has  shown  that  timely  intelligence  can  lead  to 
improved  battlefield  performance.  In  June  1941,  in  the 
Battle  of  Midway,  the  United  States  defeated  the  Japanese 
in  a  battle  that  demonstrated  how  timely  intelligence 
provided  to  the  warfighter  could  change  the  outcome  of  a 
battle.  ADM  Yamamoto  Isoroku' s  command  had  major  advantages 
in  force  structure,  technology,  training,  experience, 
morale,  and  inertia.  Yet  ADM  Chester  W.  Nimitz,  whose  only 
advantage  was  in  timely  intelligence,  was  victorious  over 
the  Japanese.  (Blackledge,  2002,  pp .  3-4) 
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The  United  States  Navy  learned  from  engagements  like 
the  Battle  of  Midway  that  timely  intelligence  was  necessary 
for  success  in  the  past.  Now  we  are  engaged  in  a  new  type 
of  warfare  —War  on  Terrorism—  where  timely  intelligence  is 
even  more  important.  Fortunately ,  at  the  same  time  that  the 
War  on  Terrorism  began,  the  Navy  was  in  the  process  of 
fielding  a  new  system,  TES-N,  which  provided  a  great 
capability  for  gathering  and  disseminating  this 
intelligence  .  However,  the  only  way  to  rapidly  deploy  this 
system  to  support  the  war  on  terrorism  was  through  an 
Evolutionary  Acquisition  following  a  Spiral  Development 
B.  THE  STEPS  THAT  LED  TO  TES-N  DEVELOPMENT 

On  September  11,  2001,  hijackers  of  two  commercial 

planes  crashed  them  into  the  twin  towers  of  the  World  Trade 
Center  in  New  York  City,  killing  all  passengers  and  large 
numbers  on  the  ground.  Later  a  third  commercial  plane  was 
crashed  into  the  Pentagon,  causing  hundreds  of  deaths  and 
turmoil  in  our  country's  center  of  military  leadership.  The 
next  crash  of  a  passenger  plane  by  terrorists  occurred  in 
Pittsburgh,  killing  everyone  onboard, 

(http : //abcnews . go . com/sections/us/DailyNews/WTC_MAIN010911 
. html)  Due  to  these  attacks.  Congress  turned  to  the 
military  to  provide  better  intelligence  for  the  United 
States.  The  Navy  responded  that  they  were  working  on  the 
development  of  JFN/TES-N,  and  Congress  then  urgently  funded 
development  of  the  TES-N  for  rapid  deployment .  According  to 
CAPT  Albert  Thomas  from  NAVSEA  IWS  6C: 

After  9/11,  Navy  received  emergency  supplemental 
funding  (DERF)  to  rapidly  deploy  NFN  capability 
in  the  form  of  TES-N  installations  and  JSIPS-N, 
GCCS-M,  and  communications  upgrades .  In  parallel 
with  executing  these  wartime  operational 
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deployments,  the  NFN  Program  office  is  developing 
plans  to  continue  spiral  development  and 
acquisition  of  ...  the  TES-N.  (NFN  Read  Ahead  for 
N76) 

Therefore,  the  Navy  adopted  an  acquisition  policy  for 
the  TES-N,  which  is  known  as  Evolutionary  Acquisition 
following  a  Spiral  Development . 

C.  THE  TES-N  EVOLUTIONARY  ACQUISITION  SPIRAL  DEVELOPMENT 
PROCESS 

The  TES-N  was  developed  due  to  an  urgent  and  strong 
need  by  the  Navy  for  the  intelligence  capabilities 
(described  above)  which  the  TES-N  could  provide  to  the 
warfighter.  Therefore,  the  normal  way  of  starting  an 
acquisition,  with  a  MNS  and  an  ORD,  was  not  followed. 
Instead,  there  was  direct  approval  from  a  Vice  Admiral  to 
start  development  of  the  TES-N  (due  partially  to  the  fact 
that  the  Army  had  already  developed  their  own  TES)  . 

(Thomas,  Interview,  2002) 

Initially  the  Army  had  developed  the  TES-A  with 

Evolutionary  Acquisition  following  a  Spiral  Development,  so 
the  Navy  joined  the  Army  Evolutionary  Acquisition  following 
a  Spiral  Development  of  TES,  which  led  to  the  Joint 

Commonality  Board  being  formed.  In  order  to  fully 

understand  the  notion  of  Evolutionary  Acquisition  following 
a  Spiral  Development  that  the  TES  took,  one  must  understand 
what  the  JCB  is  and  what  its  roles  are  for  the  TES  system. 
As  discussed  in  Chapter  II,  the  JCB  was  formed  earlier  by 
the  Army  to  help  organize  the  development  of  the  TES 
throughout  all  of  the  services  .  More  specifically,  the  JCB 
has  a  role  of  forming  and  maintaining  the  Integrated 
Product  Team  (IPT)  for  the  TES  system  development.  Each  IPT 
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is  co-managed  by  the  government  and  a  contractor,  and  each 
IPT  has  a  chief  engineer  that  it  must  answer  to  about  its 
part  of  the  system.  There  are  teams  for  functions  such  as 
security,  SIGINT,  fielding,  and  many  more.  Figure  3  shows 
how  the  TES  IPTs  are  structured.  Each  IPT  has 
representatives  from  each  service  to  make  sure  that  their 
service's  needs  are  being  met  with  each  spiral  of  the  TES. 


TES  IPTs 


CHIEF  ENGINEER 


SECURITY 

SOFTWARE 

BATTLE  MGMT  &  TGTG 

COMMS 

SIGINT 

INTEGRATED  EQUIP 

ILS 

NAT  IMINT 

INTEGRATION  &  TEST 

SIM  &  TRNG 

TAC  IMINT 

FIELDING 

XINT  &  DATA  SERVICES 


Figure  15.  Shows  the  Different  IPTs  in  the  TES-N 
Program  (From:  Lajoie,  PowerPoint  Slides,  2003)  . 

This  procedure  provides  checks  and  balances  to  assure 
that  each  service's  user  needs  are  being  met.  (Lajoie, 
Interview,  2003)  . 

The  TES-N  Evolutionary  Acquisition  following  a  Spiral 
Development  process  was  done  in  an  80/20-Spiral  Development 
schedule.  The  figure  below  represents  the  80/20-Spiral 
Development  process . 
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80/20  Spiral  Development 
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Figure  16.  This  Figure  Depicts  the  80/20  Relationship 

of  the  TES-N  Evolutionary  Acquisition  Following  a 
Spiral  Development  Process.  Entities  Listed  are 
Stakeholders  for  Each  Process  in  the  80/20 
Relationship.  (From:  Lajoie,  PowerPoint  Slides,  2003). 


The  80/20-Spiral  Development  means  that  in  the 
beginning  of  a  spiral  or  for  the  first  80%  of  the  spiral 
the  decision  making  is  done  with  the  engineers  having  a 
lead  role  about  the  development  or  systems  engineering  part 
of  the  process,  with  the  users  in  more  of  a  reactor  mode 
and  the  program  office  staying  in  the  control  mode .  In  the 
last  20  %  of  the  spiral  the  user  has  more  to  say  and  acts 
in  a  more  leading  role,  while  the  engineers  act  in  more  of 
the  reactor  mode,  and  the  program  office  still  behaves  in 
the  control  mode.  With  this  80/20  relationship  in  mind,  the 
Evolutionary  Acquisition  following  a  Spiral  Development 
goes  through  a  series  of  steps,  which  happen  in  parallel 
throughout  the  process  .  These  steps  are  known  as  USER 
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FEEDBACK,  JCB,  BUILD  PROCESS,  and  STATUS.  In  the  USER 
FEEDBACK  step,  the  program  office  and  engineers  receive 
feedback  from  users  and  actions  such  as  the  fleet.  Mobile 
training  Teams  (MTT) ,  command  visits,  CFFC  testing,  the 
DOTMLPF  filter,  and  institutional  training.  Next  the  JCB 
looks  at  the  user  requirements  and  decides  which  user 
requirements  will  be  changed  in  the  next  spiral  of  the 
system  (the  Navy  representative  on  the  JCB  serves  as  an 
advocate  for  fleet  requirements)  .  They  evaluate  such  things 
as  risk,  funding  allotted,  and  recommendations  from 
different  (IPT)  .  Once  a  list  has  been  made,  the  BUILD 
PROCESS  step  lasts  a  maximum  of  one  year.  In  this  step 
engineers  design,  develop,  test,  and  upgrade  the  new  TES 

(and  therefore  TES-N)  system.  In  the  last  activity,  STATUS, 
the  program  offices  and  IPT  analyze  what  requirements  were 
met  and  then  distribute  the  new  system.  The  process  then 
starts  all  over  again  with  the  user  assessing  the  new 

system  and  coming  up  with  feedback  to  improve  it .  With  each 
new  run  through  these  four  activities,  a  new  spiral  is 
formed  in  the  development  of  the  TES  (and  therefore  the 

TES-N)  . 

More  specifically,  the  TES-N  program  office  built  the 
basic  system  with  a  test  software  version  1.0  in  early 
1999.  They  never  fielded  version  1.0,  but  with  their  in- 

house  testing  of  it  came  up  with  a  list  of  deficiencies  . 
They  quickly  corrected  these  deficiencies  and  within  the 
same  year  developed  and  fielded  version  2.0.  The  next 
figure  gives  an  idea  of  what  new  software  was  developed  in 
each  TES-N  spiral. 
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Spiral  Development  Across  The  Services 
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. . .  Maintaining  A  Common  Baseline 


Figure  17.  This  Figure  Shows  What  Changes  Were  Added  to 

the  Software  in  Each  Spiral  of  the  TES-N  (From: 

Lajoie,  PowerPoint  Slides,  2003)  . 

D.  WHERE  THE  TES-N  PROGRAM  IS  CURRENTLY  AND  WHAT  IS  THE 

FUTURE  OF  THE  PROGRAM 

1 .  Current 

Since  the  TES-N  followed  an  Evolutionary  Acquisition 
following  a  Spiral  Development  form  of  acquisition,  the 
system  currently  has  no  Acquisition  Category  or  Navy  MDA, 
per  se.  The  NFN  (now  known  as  JFN)  MNS  which  was  signed  on 
13  Feb  02  recommended  an  ACAT  III  designation,  but  that  has 
not  been  officially  adopted.  But,  the  TES-N  does  get  a 
great  deal  of  oversight  from  many  masters,  to  include  PEO 
IWS,  all  three  SYSCOMS  (but  primarily  NAVSEA) ,  the  Virtual 
Program  Office,  and  the  OPNAV  staff.  (Burns,  2003)  Below  is 
a  more  complete  list  of  TES-N  stakeholders: 
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PEO  IWS 


JFN 


•  PEO  LSC  -  DDX 

•  PEO  SHIPS  -  CVN  77  DEVELOPMENT 

•  PEO  SUBMARINES  -  FLORIDA,  SSGN 

•  NIMA  -  IMAGERY  OVERSIGHT 

•  AGENCY  -  CLASSIFIED 

•  JCS  -  TES-J 

•  MDA  -  PROJECT  K/DSP 

•  JTAMDO  -  SWA  OPERATIONS/ATTACK  OPS 

•  ESC,  HANSCOM  -  ISRM 

•  NAVAL  RESERVES  -  LSS 

•  MARCORSYSCOM  -  TEG,  RTC 

•  ASPO  -  TES 

•  APL  -  JTAAC 

•  PEO  IEW&S  -  DCGS  ARMY 

•  MOBSTR  -  PROGRAM  OFFICE 

•  ETP  -  PROGRAM  OFFICE 

•  DARPA  -  MTES/AMSTE  II/SIAP 

•  JFCOM  -  JACKNIFE  ACTD 

•  ONR  -  X,  KU  BAND  PHASED  ARRAY  ANTENNA  DEVELOPMENT 

•  SAP  -  PROGRAM  OFFICE 

•  NAVAIR  -  HARRY  BUFFALO,  EA-6B,  JSOW  (AMSTE  II) 

•  AFRL  -  TUT 

•  FUTURE:  COAST  GUARD  -  DEEP  WATER  (Burns,  2003) 

Next,  another  important  document  which  is  called  the 
TES  ORD  by  the  TES-N  program  office  is  currently  the 
original  Army  ORD  used  with  the  TES-A  system. 
Unfortunately,  there  is  still  not  an  approved  TES-N  ORD, 
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but  on  the  other  hand,  there  is  now  a  renewed  move  to 
produce  a  JFN  ORD,  which  has  been  in  development  (and  has 
fallen  in  and  out  of  favor)  since  last  summer.  (Burns, 
2003)  As  for  the  TES-N  position  in  the  Evolutionary 
Acquisition  following  a  Spiral  Development  process,  it 
currently  has  a  fielded,  tested,  and  trained  software 
version  5.0.5.  The  program  office  has  recently  been  working 
on  Build  5.2,  which  is  essentially  a  "patch"  that  provides 
the  capability  to  test  and  demonstrate  SHARP  tactical 
Imagery  capability  in  TES-N.  Build  5.2  is  only  being 
deployed  to  Fallon  for  testing.  The  next  Version,  6.0,  is 
in  the  development /testing  stage  of  the  spiral  development 
process  and  will  be  delivered  this  fall.  Build  5.2 
capability  will  be  incorporated  into  the  6.0  software. 
(Burns,  2003) 

2 .  Future 

The  JFN/TES-N  will  continue  to  be  updated  with  new 
software,  and  the  Honorable  Mr.  Young's  recent  guidance 
states  that  the  Navy  will  converge  its  JFN  architecture 
onto  a  TES-N  baseline.  How  that  convergence  will  take 
shape  is  still  to  be  determined,  but  one  can  possibly 
foresee  ideas  such  as  JSIPS-N  capabilities  like  Precision 
Targeting  Workstation  (PTW)  and  JSIPS-N  Concentrator 
Architecture  (JCA)  being  integrated  into  TES-N.  (Burns, 
2003) 

E.  EVOLUTIONARY  ACQUISITION  FOLLOWING  A  SPIRAL 
DEVELOPMENT  OR  A  TAILORED  "TRADITIONAL"  PROCESS 

(SIMILARITIES  AND  DIFFERENCES) 

The  JFN/TES-N  program  used  Evolutionary  Acquisition 
following  a  Spiral  Development  as  described  by  Johnson  and 
Johnson  and  a  little  of  the  "traditional"  policy  described 


49 


in  the  5000  series  publications.  In  this  thesis  I  have  used 
the  Johnson  and  Johnson  model  for  Evolutionary  Acquisition 
following  a  Spiral  Development  and  the  5000  series 
documents  to  describe  the  "traditional"  process  to 
emphasize  key  points  such  as  the  Requirements  Definition, 
Acquisition  Strategy,  and  test  and  evaluation  procedure 
that  highlight  relative  differences  between  the  two  as  a 
basis  for  characterizing  the  TES-N  acquisition  process. 

The  first  key  point  was  that  the  JFN/TES-N  program  was 
developed  with  urgency,  and  from  a  previously  developed 
military  technology.  These  two  characteristics  immediately 
provide  a  fitting  reason,  as  according  to  Chapter  IV,  to 
consider  executing  Evolutionary  Acquisition  following  a 
Spiral  Development.  Additionally,  in  the  TES-N  program,  the 
Program  Manager  CAPT  Albert  Thomas,  continuously  gathers 
feedback  about  user  needs  from  operators  and  decision 
makers  using  TES-N.  But,  the  TES-N  program  office  did  not 
initially  produce  a  MNS  or  ORD  to  get  approved  for 
development  of  their  system.  (Thomas,  Interview,  2003) 

In  comparing  this  to  the  Johnson  and  Johnson  model, 
some  of  this  activity  occurs  in  what  these  authors  call  the 
Requirements  Definition  phase  of  a  program.  During,  this 
activity  the  user  is  involved  up  front  and  needs  to  be 
continuously  consulted  for  each  spiral  of  the  development. 
Next  in  the  Requirements  Definition  phase,  the  program 
office  must  establish  a  SRD,  but  this  did  not  happen  in  the 
TES-N  program.  The  user' s  essential  requirements  for  the 
system  are  listed  in  the  SRD,  but  the  user  also  understands 
that  the  system  will  be  less  than  80%  effective.  The  TES-N 
program  did  not  have  an  SRD,  but  consulted  an  old  ORD  from 
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the  Army  TES-A  program.  They  also,  later  in  the  program 
development,  produced  a  MNS  that  was  similar  to  the 
"traditional"  approach  outlined  in  the  5000  series 
documents,  but  was  not  written  in  the  order  that  the 
"traditional"  approach  follows  .  Below  is  an  example  of  an 
objective  from  the  MNS  of  the  JFN/TES-N  program.  It  states: 

Objectives.  To  generate  targets  by  collecting  and 
collating  detection  data  gleaned  from  a  variety 
of  dispersed  sensors  and  sources  including  sub¬ 
surface,  surface,  air-breather  or  space-based, 
fusing  and  transmitting  that  data  to  cognizant 
commanders  for  threat  evaluation,  and  engagement 
platforms  for  weapons  assignment  in  support  of 
the  Joint  Force  Commander's  objectives.  This  MNS 
documents  the  need  to  convey  relevant  information 
required  by  the  warfighter  throughout  the 
"Detect-Cont rol-Engage"  sequence .  (Mission  Need 
Statement  For  Naval  Fires  Network  (NFN)  ACAT  III, 

p  .  2 ) 

This  MNS  does  reflect  the  5000  series  publications  but 
it  was  not  done  in  the  same  sequence  as  the  5000  series 
documents .  This  MNS  statement  was  produced  after 
development  and  fielding  of  the  system  had  taken  place,  not 
before  the  system  was  approved  for  Concept  Exploration. 

Next,  the  program  office  had  an  Acquisition  Strategy 
for  putting  the  requirements  into  action.  In  the  TES-N 
program,  this  was  done  through  the  JCB  and  the  TES  IPT.  The 
JCB  and  TES  IPT  provided  constant  communication  for  the 
project .  In  visiting  the  program  office,  CAPT  Thomas  seemed 
busy,  continuously  finding  new  user  requirements  and  then 
vetting  out  which  ones  could  be  solved  and  which  ones  would 
be  held  to  the  next  spiral.  This  gave  me  the  idea  that  he 
understood  that  his  program  never  had  an  end  capability  and 
that  it  would  always  be  changing  to  take  advantage  of 
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changing  technology.  According  to  Johnson  and  Johnson,  in 
the  Acquisition  Strategy  for  Evolutionary  Acquisition 
following  a  Spiral  Development,  the  Program  Manager 
constantly  looks  for  new  user  requirements  for  the  next 
spiral  and  they  understand  that  there  is  flexibility  in 
their  program,  meaning  there  is  no  need  to  be  rigidly  fixed 
on  the  end  product.  This  was  similar  to  what  happened  with 
the  TES-N  program. 

Next,  the  testing  community  in  an  Evolutionary 
Acquisition  following  a  Spiral  Development  also  cannot  be 
fixed  on  the  end  capability.  The  TES-N  program  did  not 
follow  the  "traditional"  test  and  evaluation  phase,  due  to 
the  fact  that  they  had  no  ORD  to  be  tested,  and  they  still 
wanted  a  fast  development  of  the  capability.  (Lajoie, 
Interview,  2003)  Instead,  testing  was  done  in  events  such 
as  LOE  and  FBE .  For  example,  a  TES-N  prototype  was 
successfully  demonstrated  in  Fleet  Battle  Experiment-India 
(FBE-I),  an  exercise  event  involving  all  four  services 
conducted  in  June  2001.  Based  upon  this  successful 
demonstration,  COMTHIRDFLT  recommended  immediate  deployment 
of  JFN  aboard  USS  JOHN  C.  STENNIS  (CVN  74)  and  USS  ABRAHAM 
LINCOLN  (CVN  72),  with  COMNAVAIRPAC  citing  JFN  as  a 
"critical  capability."  (Burns,  2003)  CNO  (N7)  recommended 
immediate  acquisition  and  deployment  of  JFN/Time  Critical 
Strike  capability.  In  July  2001,  the  Assistant  Secretary 
of  the  Navy  (Research,  Development  and  Acquisition)  (ASN 
RDA)  designated  a  Naval  Fires  Network/Time  Critical  Strike 
Program  Director  to  integrate  and  synchronize  acquisition 
and  deployment  activities  across  the  Navy’s  Systems 
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Commands.  Currently  there  is  no  efficient  testing  procedure 
on  Evolutionary  Acquisition  following  a  Spiral  Development, 
but  doctrine  is  being  developed.  (Burns,  2003) 


53 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


54 


VI .  CONCLUSIONS 


This  chapter  provides  conclusions  and  recommendations 
on  what  can  be  improved  and  what  should  be  used  in  future 
acquisition  programs  such  as  the  TES-N. 

Evolutionary  Acquisition  following  a  Spiral 
Development  shown  with  the  TES-N  system  is  an  acquisition 
policy  of  the  future  .  This  thesis  shows  that  Evolutionary 
Acquisition  following  a  Spiral  Development  with  the 
JFN/TES-N  system  is  an  acquisition  policy  that  is 
appropriate  for  programs  of  the  same  size  and  scope,  but 
larger  more  complex  programs  will  not  have  as  much  success. 
This  Evolutionary  Acquisition  following  a  Spiral 
Development  for  small/low  complexity  programs  provides 
faster  implementation  of  the  system,  involves  the  user 
throughout  the  process,  and  allows  each  service  to  be  up  to 
date  with  the  changing  effects  of  technology.  Yet,  despite 
all  these  benefits,  there  is  still  some  work  that  must  go 
into  other  policies  that  affect  Evolutionary  Acquisition 
following  a  Spiral  Development .  After  a  more  in-depth  look 
into  the  TES-N  program,  one  can  see  that  future  programs 
following  this  type  of  acquisition  policy  will  have  issues 
with  areas  such  as  budgetary  submission,  the  role  of 
OPTEVFOR  in  their  programs,  policy,  process,  and  training. 

A.  OPINIONS  AND  BENEFITS 

In  interviewing  many  officers,  I  found  that  varying 
opinions  have  been  formed  regarding  JFN/TES-N  in  the  Navy. 
According  to  CAPT  Paul  Hill,  SPAWAR  05  Deputy  for  JFN,  the 
JFN/TES-N,  system-of-systems ,  has  shown  that  Evolutionary 
Acquisition  following  a  Spiral  Development  will  provide 
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tremendous  improvements  in  technological  capabilities  and 
attributes,  but  it  has  also  proved  that  it  is  way  ahead  of 
its  CONOPS.  (Hill,  2003)  This  means  that  the  technology  is 
updated  effectively  but  the  support,  logistics,  and 
training  policies  cannot  keep  up  with  these  new 
capabilities.  Listed  below  are  attributes  and  capabilities 
of  TES-N  received  from  the  Program  Office.  Next,  CAPT 
Christopher  Bott,  Commander  Third  Fleet,  J2,  stated  that 
the  JFN/TES-N  concept  of  a  single  box  capability,  which 
allows  access  in  real  time,  is  a  good  one.  He  further 
states  TES-N  is  nearly  ready  but  still  is  lagging  with 
inter-system  problems  between  TES-N  and  GCCS-M;  in 
addition,  the  graphics  could  be  improved.  (Bott,  2003) 
Furthermore,  CDR  Olivarez,  a  strike  Commander  aboard  the 
USS  CORONADO,  he  commented  that  when  he  was  aboard  the  USS 
LINCOLN,  he  found  that  not  many  operators  knew  how  to  use 
the  TES-N.  In  addition,  operators  and  aviators  needed  to 
understand  each  other's  requirements  for  TES-N.  (Olivarez, 
2003) 

B.  LIST  OF  CAPABILITIES  AND  ATTRIBUTES  THAT  JFN/TES-N 
PROVIDED 

•  Attributes : 

•  Competitive  award 

•  100%  Government  owned 

•  Non-proprietary 

•  Spiral  development 

•  Configuration  managed  by  a  4  Service  JCCB 

•  Common  software  baseline 

•  Over  65%  of  content  by  other  contractors 

•  Common  workstations  for  all  Services 
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Multi-INT  architecture : 

•  Sensor  access,  control  and  management 

•  Situational  awareness 

•  Mission  planning  and  monitoring 

•  Exploitation 

•  Communications  and  dissemination 

Software  Architecture : 

•  Open  and  Non-proprietary 

•  ICDs  and  APIs  documented  but  controlled  by 
Government 

•  Commercial  standards  compliant 

•  Over  115  COTS/GOTS  products  integrated 

•  IP  based  internal  and  external  network 
interfaces 

Scalable : 

•  Hosted  on  a  variety  of  platforms  across  all 
Services;  Vannized,  shipboard,  rack  mounted, 
transit  case,  and  airborne 

•  Software  is  issued  in  a  configuration- 
managed  version  across  all  Services. 

•  Major  upgrade  typically  once  per  year,  minor 
upgrades  as  needed. 

•  Service  may  chose  not  to  purchase  a 


particular 
fielded) . 


COTS 


license  (capability  not 


Jointness : 


Over  40  systems  fielded  and  operating  world¬ 
wide 

OIF  supported  by  a  TES  variant  from  each 
Service 

Supports  National  thru  Unit  level 
Sharing,  files,  data,  Intel  daily 
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•  Footprint  TES  supports  other  disadvantaged 
nodes 

•  Army:  TES  Forward,  TES  Main,  DTES 

•  Navy:  TES-N,  RTC,  RTC  Lite 

•  USMC :  TEG,  RTC 

•  Air  Force:  ISR-M  Host,  ISR-M  Remote  (Burns, 
2003) 

Even  with  these  impressive  capabilities,  the  JFN/TES-N 
acquisition  still  encountered  issues  in  other  policies  that 
needed  to  be  addressed.  This  includes  policies  in  budgetary 
submissions,  test  and  evaluation,  general  policy  and 
process  in  the  Navy,  and  training. 

C.  DRAWBACKS:  FUNDING,  TEST  AND  EVALUATION,  POLICY, 

PROCESS,  AND  TRAINING 

The  TES-N,  due  to  its  acquisition  policy  of 
Evolutionary  Acquisition  following  a  Spiral  Development, 
did  not  use  traditional  methods  in  funding,  test  and 
evaluation,  policy,  process  and  training.  In  order  to  avoid 
similar  problems  in  Evolutionary  Acquisition  following  a 
Spiral  Development  for  future  programs  following  this  new 
acquisition  policy,  there  must  be  new  procedures  for  test 
and  evaluation,  budgetary  submissions,  policy,  process,  and 
training  in  the  Navy. 

1 .  Funding 

a .  Problem 

Traditionally,  as  according  to  the  5000  series 
documents  and  as  described  in  Chapter  III,  funding  is 
conducted  according  to  the  Planning,  Programming,  and 
Budgeting  System  (PPBS) .  The  TES-N  program  could  only 
partially  follow  the  guidelines  of  the  PPBS  because  they 
used  the  Army's  funding  documents  of  the  TES-A  program.  The 
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TES-N  program  office  can  realistically  provide  an  estimate 
of  how  much  money  they  intend  to  spend  over  the  next 

several  years  and  what  they  intend  to  use  it  for,  but  in 
reality,  due  to  the  Evolutionary  Acquisition  following  a 
Spiral  Development,  the  program  office  only  knows  how  much 
funding  they  will  need  in  the  future  once  the  users' 
feedback  is  obtained.  User  feedback  is  only  received  after 
the  new  development  is  brought  into  the  fleet;  therefore 

the  time  constraints  for  Evolutionary  Acquisition  following 

a  Spiral  Development  do  not  allow  for  a  funding  policy  that 

acts  in  accordance  with  the  PPBS .  Moreover,  other  programs 
like  the  TES-N  might  not  have  prior  programs  to  base 
funding  on  for  the  PPBS.  In  conclusion,  since  each  spiral 
depends  on  the  previous  spiral  there  is  no  way  a  program 
manager  can  produce  a  Program  Objectives  Memorandum  (POM) 
for  years  in  the  future.  (Lajoie  and  Thomas  Interviews, 
2003) 

b.  Solution 

In  my  opinion  there  is  not  yet  a  clear  and 

definite  answer  to  this  problem.  A  recommendation  based 
upon  research  for  this  thesis  would  be  that  Program 

Managers  of  Evolutionary  Acquisition  following  a  Spiral 
Development  need  to  work  on  explaining  and  teaching  to  the 
budgetary  submission  analysts  how  Evolutionary  Acquisition 
following  a  Spiral  Development  works  and  that  funding 

requirements  are  obtained  only  once  user  feedback  is 

received.  The  Program  Managers  need  to  do  this  until  the 
budgetary  submission  analysts  buy  into  the  unique  funding 
developments  of  Evolutionary  Acquisition  following  a  Spiral 
Development . 
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2 .  Test  and  Evaluation 
a .  Problem 

For  each  new  development  of  a  system,  there  must 
be  some  sort  of  test  and  evaluation  to  determine  if  the 
system  is  ready  for  delivery  to  the  fleet.  In  the  5000 
series  documents,  and  as  explained  in  Chapter  III,  the 
testing  role  is  lead  by  OPTEVFOR.  This  process  is  usually  a 
very  long  and  detailed  process.  Since  the  TES-N  was 
developed  in  Evolutionary  Acquisition  following  a  Spiral 
Development  for  quick  fleet  operational  capability,  it 
bypassed  the  OPTEVFOR  stage  and  went  directly  to  the 

certification  stage  for  implementation  into  the  fleet. 

Later  in  the  TES-N  development  program,  Commander  Fleet 
Forces  Command  (CFFC)  requested  OPTEVFOR  to  test  TES-N,  but 
OPTEVFOR  was  not  sure  what  or  how  to  test  since  there  was 
no  new  ORD  produced  and  the  Army  ORD  had  already  been 
tested.  In  conclusion,  this  part  of  the  TES-N  acquisition 
needs  to  be  revised  for  future  systems  so  OPTEVFOR  can 
clarify  and  then  fulfill  its  role  in  testing  a  program  that 
has  Evolutionary  Acquisition  following  a  Spiral 
Development.  (Lajoie,  Interview,  2003) 
jb.  Solution 

According  to  a  contractor  for  JFN' s  resource 
sponsor,  N61,  David  Loneman,  one  cannot  do  away  with  Test 
and  Evaluation  (T&E)  and  the  role  of  the  testers  (OPTEVFOR) 
but  the  internal  organization  needs  to  be  changed.  If  you 
did  away  with  T&E  the  fleet  would  not  feel  comfortable 

using  the  product  developed.  A  solution  to  this  might  be 
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hiring  more  people  so  the  process  of  test  and  evaluation  is 
faster  to  keep  up  with  technology  but  still  is  as 
efficient.  (Loneman,  2003) 

Due  to  the  changing  policies  in  acquisition,  I 
believe  the  role  of  OPTEVFOR  and  documentation  on 
parameters  for  testing  should  be  changed,  too.  For  example 
with  the  JFN/TES-N,  the  Evolutionary  Acquisition  following 
a  Spiral  Development  was  done  in  an  80/20-Spiral 
Development  schedule.  Usually  OPTEVFOR  tests  compliance 
with  the  ORD  but  in  Evolutionary  Acquisition  following  a 
Spiral  Development  no  ORD  requirements  will  be  initially 
produced.  In  my  opinion  with  this  80/20  relationship  in 
mind,  OPTEVFOR  should  be  provided  different  levels  of  ORD 
requirements  to  review.  This  would  include  initial  testing, 
midterm  testing  and  then  a  final  testing  when  each 
requirement  is  met  (the  final  testing  might  not  come  for 
many  spirals  so  they  would  have  to  be  patient) .  So 
initially  we  would  have  more  of  a  70/20/10  relationship 
(Engineers,  Users,  OPTEVFOR) .  OPTEVFOR  needs  to  be  involved 
early  in  the  project  to  make  sure  the  project  is  safe, 
while  at  the  same  time  not  delaying  the  program  for  fleet 
use.  Then  at  midterm  a  60/20/20  relationship  (Engineers, 
Users,  OPTEVFOR)  should  be  used  in  Evolutionary  Acquisition 
following  a  Spiral  Development.  Finally  when  capability  is 
complete  then  it  would  become  a  40/40/20  relationship.  This 
means  OPTEVFOR  is  always  in  on  the  workings  of  the  program 
and  does  not  have  to  wait  to  the  end  to  test.  According  to 
VADM  (RET)  Ted  Parker,  this  kind  of  arrangement  for 
OPTEVFOR  I  suggested  above  can  work,  and  has  worked  in  the 
past.  He  also  commented  on  other  suggestions  such  as: 
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Getting  OPTEVFOR  OTDs  involved  very  early  is 
healthy  for  any  program  and  especially  important 
if  one  is  not  quite  sure  what  the  route  is  to  the 
final  set  of  requirements.  If  this  is  done,  the 
OTDs  gain  better  understanding  of  what  the 
developmental  item  really  is,  and  can  apply 
better  judgment  to  issues  that  arise.  In  my 
experience,  this  permits  a.  much  more  opportunity 
for  DT&E  to  produce  data  that  is  useful  to 
Operational  Evaluation  of  the  system.  Sometimes, 
it  just  requires  a  simple  change  (that  can  be 
suggested  by  the  OTD)  to  make  a  test  that  has  no 
operational  content  into  one  that  has  enough 
operational  content  that  the  results  can  be 
applied  toward  IOT&E.  b.  utilization  of  more  DT&E 
data  and  better  understanding  of  the  system.  This 
will  usually  avoid  the  problem  of  dumb  tests 
being  conducted  and  paid  for  (saves  money  and 
time)  .  c.  better  thinking  by  the  PM,  because 
he/she  will  have  an  opportunity  to  understand  the 
needs  of  the  OTD  and  can  get  ready  for  them  (do 
better  in  OT&E) .  (Parker,  2003) 

In  conclusion,  OPTEVFOR  and  program  offices  that 
use  Evolutionary  Acquisition  following  a  Spiral  Development 
need  to  work  together  to  make  a  test  and  evaluation  policy 
that  will  be  efficient  with  this  new  form  of  acquisition. 

3.  Policy  and  Process 
a.  Policy 

(1)  Problem.  Some  policies  of  the  Navy  need 
to  be  changed.  Policy  was  done  differently  for  the  JFN/ 
TES-N  form  of  acquisition.  For  example,  there  was  constant 
leadership  throughout  this  program.  The  Navy  made  a 
decision  to  leave  the  Program  Manager,  CAPT  Thomas,  in  the 
same  position  since  1996.  In  acquisition  programs  such  as 
Evolutionary  Acquisition  following  a  Spiral  Development  it 
is  critical  to  have  the  same  leadership  since  it  takes  a 
long  time  to  understand  issues  and  make  changes  to  the 
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program.  If  they  had  reassigned  him  the  program  would  have 
eventually  collapsed  or  fell  behind.  (Thomas,  Interview, 
2003) 

(2)  Solution.  According  to  CAPT  Thomas, 
the  Program  Manager  for  the  JFN/TES-N,  the  Department  of 
the  Navy  should  change  their  officer  career  path  for 
acquisition.  For  example,  the  pipeline  would  continue  as 
normal  until  X.O.  level.  At  X.O.  level,  the  board  would 
screen  officers  for  acquisition  billets.  Then,  if  awarded 
acquisition  billets  those  officers  would  spend  the  next  15 
years,  plus,  in  acquisition.  They  would  first  act  as  Deputy 
Program  Managers  so  that  they  would  get  initial 
understanding  of  the  job.  According  to  CAPT  Thomas,  it 
takes  time  to  understand  the  Program  Manager  concepts. 
Next,  the  Navy  would  promote  a  percentage  of  the  Deputy 
Program  Managers  to  Program  Managers.  As  Program  Managers, 
they  would  stay  on  that  specific  program  until  the  project 
was  complete  or  they  were  deemed  incompetent.  Also,  by  not 
moving  them  until  the  project  was  finished,  it  would  let 
the  Program  Manager's  workers  know  that  he/she  was  not 
going  anywhere,  which  would  curtail  "slow  rolling"  to  wait 
for  change  of  leadership.  (Thomas,  Interview,  2003) 

Within  this  new  policy,  one  needs  to  ensure 
integrity  in  the  system  being  worked  on.  An  answer  to  this 
would  be  to  give  a  bonus  to  keep  the  Program  Managers  from 
retiring  and  working  for  the  contractor  when  they  retire. 
Next,  there  needs  to  be  a  structure  to  account  for  human 
nature.  Most  people  in  the  acquisition  business  seem  to  be 
very  ambitious,  aggressive,  and  very  competent.  But,  when 
there  are  large  sums  of  money  involved,  people  can  be 
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corrupted.  Therefore  everyone  involved  in  the  project  needs 
to  have  a  personal  interest  to  be  successful.  (Thomas, 
Interview,  2003) 

b .  Process 

(1)  Problem.  This  program  also  reveals  a 

struggle  that  the  Navy  has  in  its  process  and  a  problem 

that  might  hold  back  future  progress  in  fielding 
technological  support  to  this  program.  This  problem  builds 

back  up  for  user  buy  ins  and  training.  For  example,  since 

Evolutionary  Acquisition  following  a  Spiral  Development  has 
been  adopted  it  has  created  tension  between  three  different 
groups  of  people:  OPTEVFOR  and  the  developers,  the 
operators  of  the  TES-N  and  the  idea  of  having  new  system 
ownership,  and  tensions  between  the  different  mentalities 
of  the  Pacific  and  Atlantic  Fleets.  In  LCDR  Matt  Hopson's 
opinion,  the  J2  Systems  officer  on  USS  CORONADO,  the 

capabilities  of  TES-N  are  there  but  there  is  a  lack  of 
teamwork  and  proficiency  throughout  the  project.  For 

example,  OPTEVFOR  needs  to  work  with  the  developers,  and 
the  developers  need  to  work  with  OPTEVFOR  to  find  a  way  to 
efficiently  test  the  Evolutionary  Acquisition  following  a 
Spiral  Development  process  without  taking  four  years,  and 
still  keeping  in  mind  that  the  capability  is  not  yet 
finished.  The  Navy  also  needs  to  challenge  its  operators  to 
take  ownership  of  the  new  system  and  work  with  each  other 
to  make  sure  it  is  producing  the  correct  display  of  data. 
Finally,  there  needs  to  be  an  alliance  between  the  Pacific 
and  Atlantic  Fleets  to  install  this  system  in  both  fleets 
at  the  same  time.  This  system  is  supposed  to  provide 
interoperability  between  all  the  services,  but  the  Pacific 
Fleet  is  the  only  one  using  it  in  the  Navy.  Thus,  the  Navy 
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has  moved  away  from  this  stovepipe  philosophy  with 
Evolutionary  Acquisition  following  a  Spiral  Development  and 


it  needs 

to  do  this  also  with 

its 

processing 

procedures . 

(Hopson, 

2003) 

(2)  Solution. 

One 

possible 

solution 

according 

to  Destiny  Burns 

from 

the  program  office. 

involves  creating  greater  fleet  ownership  of  the  system 
through  an  institution  of  combined  formal  schoolhouses,  on¬ 
site  training,  and  more  "train-the-trainer"  type  of 
activities,  establishment  of  formal  TES-N/JFN  billets  and 
transition  of  logistics  activities  from  the  contractor  to 
the  fleet.  (Burns,  2003)  An  example  of  a  near  term  plan 
related  to  these  tasks  is  that  during  Fiscal  Year  2003,  the 
JFN  Program  Office  established  a  customer  support  strategy 
to  engage  Fleet  users  in  the  assessment /development  of  a 
Performance  Based  Logistics  (PBL)  strategy  in  accordance 
with  ASN  (RDA)  Memorandum  PBL  Guidance  Document  of  27  Jan 
2003.  Interim  Defense  Acquisition  Guidebook  of  30  Oct  2002 
states  that  Program  Managers  shall  establish  logistics 
support  concepts  and  refine  concepts  throughout  program 
development.  JFN  shall  coordinate  program  requirements  for 
support  across  functional  areas  to  minimize  redundant 
contract  deliverables  and  inconsistencies.  A  JFN  Product 
Support  Plan  is  being  developed  for  all  fielded  JFN 
systems.  The  Product  Support  Plan  includes  methods  and 
tools  to  track  system  performance,  such  as  designation  of  a 
JFN  System  Officer  associated  with  each  fielded  system,  to 
enhance  coordination  and  implementation  of  formal  and 
informal  reporting  and  feedback  procedures  such  as: 


65 


Sailor-to-Engineer  Website  Access 
Navy  Integrated  Call  Center 
Remedy  Database  (Burns,  2003) 


• 

Another  key  JFN  Integrated  Logistics  Support 
(ILS)  strategy  is  the  transition  of  depot  support,  sparing, 
and  maintenance  support  from  contractor  to  government 
(fleet)  control  and  responsibility.  (Burns,  2003) 

4 .  Training 

a .  Problem 

As  everyone  knows,  technology  can  not  be  used  if 
no  one  knows  how  to  use  it.  The  TES-N  training  system  has 
caused  a  delay  in  the  use  of  TES-N  operationally. 
Currently,  the  normal  training  schedule  is  constant 
training  on  the  system  for  ten  days  (65  hours)  .  TES-N  is 
not  typically  used  right  away,  so  when  the  operators  are 
about  to  use  it  they  are  given  a  quick  refresher  course. 
Therefore,  there  is  a  huge  gap  between  training  and  system 
use,  which  causes  proficiency  to  go  drastically  down. 
(Hopson,  2003)  This  will  be  viewed  from  the  results  of  a 
survey  I  conducted  on  06MAY03  and  07MAY03  given  to  the 
operators  and  decision  makers  of  the  JFN/TES-N  aboard  the 
USS  CORONADO. 

Table  1  presents  results  of  a  survey  used  to  rate 
the  effectiveness  of  the  JFN/TES-N  training.  It  displays 
the  mean  score  and  range  from  lowest  to  highest  for  each 
question,  using  a  seven-point  scale.  Participants  were 
asked  to  rate  the  number  on  the  seven-point  scale  with 
which  they  best  agreed.  The  seven-point  scale  ranged  from 
1=  Not  at  all  Effective  or  Extremely  Difficult  (depends  on 
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the  question)  to  7  =  Extremely  Effective  or  Extremely  Easy 
(depends  on  the  question)  .  Below  is  an  example  of  the 
scales  used  in  the  survey. 

1 _ 2 _ 3 _ 4 _ 5 _ 6 _ 7 

Not  Somewhat  Moderately  Very  Extremely 

Very  Extremely  Effective  Effective  Effective 

Effective 

1 _ 2 _ 3 _ 4 _ 5 _ 6 _ 7 

Extremely  Very  Moderately  Very  Extremely 

Difficult  Difficult  Dif f icult/Easy  Easy  Easy 

The  survey  was  administered  to  11  operators  and  decision 
makers  of  the  JFN/TES-N;  11  completed  surveys  were  returned 
and  analyzed. 


Survey  Question  Mean  Range 


1 . 

How  effective  was  the  training  to  operate 
TES-N? 

4 

(2-5) 

2  . 

How  easy  was  it  to  learn  to  use  the  TES-N? 

3 . 6 

(2-6) 

3  . 

How  effective  was  the  actual  process  that 
was  used  (meaning  combining  all 
intelligence  people  to  work  together)  to 
implement  the  new  TES-N? 

4 . 7 

(2-6) 

Table  1.  Results  of  Survey  on  Effectiveness  of 

JFN/TES-N  Training. 

The  question  that  asked  about  the  effectiveness 
of  the  TES-N  training  received  a  mean  rating  of  4, 
indicating  that  it  was  moderately  effective.  Two 
participants  stated  that  the  trainers/contractors  were 
better  suited  for  tech  support  than  operator  training.  They 
explained  that  lots  of  training  time  was  wasted  due  to  the 
trainer's  lack  of  operator  experience  with  the  machine. 
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Another  participant  stated  that  they  had  received  only  on- 
the-job  training,  which  was  helpful,  but  without  formal 
training  and  constant  use  the  training  was  not  effective. 
Also  an  operator  explained  that  the  training  was  good  but 
the  UNIX  environment  that  JFN/TES-N  operated  in  was  non¬ 
familiar  and  slowed  the  learning  curve  for  many  operators. 

The  next  question  asked  about  how  complicated  the 
TES-N  was  to  learn.  The  mean  rating  for  this  item  was  3.6, 
indicating  that  it  was  more  than  moderately  difficult.  One 
participant  stated  that  a  reason  TES-N  was  difficult  to 
learn  was  because  there  were  so  many  parts  to  JFN/TES-N  and 
many  operators  and  decision  makers  did  not  practice  using 
them  everyday.  Another  operator  commented  that  it  needed  to 
be  more  user-friendly  since  the  system  step/functions  were 
not  intuitive  and  there  were  too  many  steps  involved  in 
completing  one  task.  In  contrast,  another  operator 
commented  that  it  seemed  fairly  user-friendly,  especially 
if  you  have  a  motivated  instructor  and  get  hands-on 
training,  then  anyone  should  be  able  to  learn  the  system. 

The  next  question  asked  about  the  effectiveness 
of  the  actual  process  that  was  used  (meaning  combining  all 
intelligence  people  to  work  together)  to  implement  the  new 
TES-N.  The  mean  rating  for  this  question  was  4.7,  which 
indicates  that  is  was  greater  than  moderately  effective. 
One  operator  rated  this  item  as  a  5  since  the  proximity  of 
all  the  intelligence  sources  and  adaptation  to  the  type  of 
intelligence  flow  allowed  more  timely  fusion  of 
intelligence.  Another  operator  agreed  and  said  the  process 


68 


was  effective  last  summer  for  the  Millennium  Challenge 
Exercise.  Another  operator  commented  that  better  training 
would  help  the  process  run  even  smoother. 

With  these  survey  questions  analyzed  I  conclude 
that  training  of  the  TES-N  needs  to  be  improved.  It  seems 
that  most  operators  and  decision  makers  get  on  the  job 
training  and  not  formal  training  of  the  JFN/TES-N.  If 
formal  training  is  given  then  it  is  limited.  Furthermore, 
hands-on  experience  with  the  system  is  not  occurring  after 
training  is  completed,  therefore  knowledge  is  lost. 
Furthermore  most  Navy  personnel  have  been  trained  on 
Windows  and  not  UNIX,  which  causes  problems  since  the 
operating  system  of  TES-N  is  UNIX.  In  addition,  the 
training  system  also  could  be  easier  to  utilize,  meaning 
there  are  too  many  steps  to  complete  a  task.  Finally,  the 
TES-N  process  of  combining  all  intelligence  people  to  work 
together  seems  to  work  but  would  run  smoother  with  more 
formal  training  and  better  doctrine. 

jb.  Solution 

A  solution  to  the  training  dilemma  might  be  to 
follow  what  the  Army  initially  did.  The  Army  did  their 
initial  training  a  different  way.  They  formed  a  TES 
organization  before  they  started  the  development  of  the 
TES-A.  This  organization  included  experienced  operators  who 
were  hand  picked.  (Thomas,  Interview,  2003)  This 
integration  went  a  lot  smoother.  Next,  the  Navy  could  have 
sent  more  people  to  the  Army  training  center  to  get  more 
formal  training  instead  of  on-the-job  training  for  the 
JFN/TES-N.  Finally,  there  should  be  a  human  factors 
training  person  involved  in  the  initial  spiral  development 
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of  the  system  so  they  can  help  ensure  a  good  Human  System 
Interface  and  document  how  to  operate  the  new  system  as  it 
is  being  developed. 

This  thesis  concludes  that  Evolutionary 
Acquisition  following  a  Spiral  Development  shown  with  the 
JFN/TES-N  system  is  an  acquisition  policy  that  is 
appropriate  for  programs  of  the  same  size  and  scope,  but 
larger  more  complex  programs  will  not  have  as  much  success. 
Yet,  in  order  for  the  JFN/TES-N  program  and  future  programs 
using  Evolutionary  Acquisition  following  a  Spiral 
Development  to  succeed  changes  have  to  be  made  in  policies 
such  as  budgetary  submissions,  test  and  evaluation,  policy, 
process,  and  training. 
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